Pentla - Acceptance Criteria Dashboard

pentla-api STALE
main 81340c2 chore(db): add pentla_owner/pentla_runtime functio... 3 h ago
e2e 2030267 239 ACs 15 h ago
pentla-frontend STALE
main 936cc9f feat(orders): tailor cranial order detail and surf... 4 d ago
e2e e3b2e73 283 ACs 6 d ago
Organisation
34%
72 ready, 83 partial of 210
Patients
6%
19 ready, 65 partial of 314
Orders & Configuration
8%
15 ready, 34 partial of 179
Component Trees
2%
2 ready, 11 partial of 112
Component Catalogue
0%
0 ready, 24 partial of 112
Overall Progress 108 of 927 ready (12%)
108 ready (both BE + FE) 217 partial (one side) 602 not ready
Implementation Notes 111 annotated ACs + 19 spec issues
SPEC Needs Product Decision 30
Specs the PM must resolve before these ACs can be tested. GitHub spec issues open on Pentla-tech/pentla-specs.
ACs needing decision
AC-ORG-223 Organisation [CPO] Invitation expiry: links expire after a configurable window (default: 7 days). Resending invalidates previous links Invitation expiry configurability - pending product decision AC-ORD-030 Orders & Configuration [BOTH] The configurator displays a visual representation of the device — not a form with dropdowns Visual device representation - configurator is visual but spec wording needs clarification AC-ORD-030 Orders & Configuration [CPO] An on-hold order can be rejected directly without returning to READY_FOR_PRODUCTION first Visual device representation - configurator is visual but spec wording needs clarification AC-CTE-102 Component Trees [CO] Solid AFO tree: shell (with proximal trim as specification), footplate, posterior strap, calf cuff, instep strap (conditional — deep-shell override), padding, liner (conditional on laminated fabrication at DEVICE level), lateral/medial support (per-side valgus/varus, valid across bilateral pairs), T-strap (conditional on tibial torsion), growth margin (conditional on paediatric), rocker bottom, sole insert — positions, per-side alignment rules, and clinical workflow order are clinically accurate Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-103 Component Trees [CO] Articulated AFO tree: hinge selection triggers appropriate ankle joint dependencies Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-104 Component Trees [CO] Transtibial prosthesis: socket assembly (socket shell, socket adapter), liner, suspension (11 types: PASSIVE_SUCTION, ACTIVE_SUCTION, SAS, HYBRID_LOCK, PIN_LOCK, LANYARD, SUPRACONDYLAR, SUPRACONDYLAR_CUFF, ANATOMIC, CUFF_STRAP, FIGURE_EIGHT_STRAP — with bidirectional liner-suspension rules), functional adapter, pylon, foot, ankle adapter — positions, dependencies, and clinical workflow order are clinically accurate Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-105 Component Trees [CO] Transfemoral prosthesis: socket assembly (socket shell, socket adapter), liner, suspension (7 types: PASSIVE_SUCTION, ACTIVE_SUCTION, SAS, HYBRID_LOCK, PIN_LOCK, LANYARD, KISS — with suspension sleeve, socket valve, vacuum pump, auxiliary belt, and bidirectional liner rules), knee unit (4 types with charging dock/battery charger cascade), functional adapter, pylon, foot, ankle adapter — positions, dependencies, and clinical workflow order are clinically accurate Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-112 Component Trees [CO] Knee disarticulation prosthesis: socket assembly (socket shell, socket adapter, socket windows conditional on condyle prominence at DEVICE level), liner, suspension (6 types: ANATOMIC, PASSIVE_SUCTION, ACTIVE_SUCTION, SAS, LANYARD, KISS — with suspension sleeve, socket valve, vacuum pump, auxiliary belt, and bidirectional liner rules), knee unit (3 polycentric types with charging dock/battery charger cascade for microprocessor), functional adapter, pylon, foot, ankle adapter — positions, dependencies, condyle prominence as primary structural classifier, and clinical workflow order are clinically accurate Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-106 Component Trees [CO] Protective helmet: shell (fabrication method, and method-specific attributes — shell colour + design pattern + optional vapor smoothing finish for 3D-printed, transfer paper (First Choice and Backup Choice — both required before the order can move past DRAFT; 'Pick pattern later' is a tickbox that lets the CPO keep working on the rest of the order without warnings while parents decide, but it doesn't skip the requirement) for thermoplastic), comfort padding (single spec: coverage, material, thickness, colour, protective layer, and method-specific perforation attribute — Padding Perforation for 3D-printed with Perforated default, Helmet Perforation for thermoplastic with Don't perforate default), closure (auto-selected by fabrication method), forehead protection and chin protection as optional additions — no node-visibility conditionals; perforated padding-material variants hidden from catalogue for thermoplastic Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-107 Component Trees [CO] Corrective helmet: shell (fabrication method, and method-specific attributes — shell colour + design pattern + optional vapor smoothing finish for 3D-printed, transfer paper (First Choice and Backup Choice — both required before the order can move past DRAFT; 'Pick pattern later' is a tickbox that lets the CPO keep working on the rest of the order without warnings while parents decide, but it doesn't skip the requirement) for thermoplastic; shell designed around the patient's 3D scan with design file linked to order), padding (single spec: coverage, material, thickness, colour, and method-specific perforation attribute — Padding Perforation for 3D-printed with Perforated default, Helmet Perforation for thermoplastic with Don't perforate default; allergy-incompatible materials hidden from catalogue; perforated padding-material variants hidden from catalogue for thermoplastic; protective layer surfaced only when the atopic dermatitis clinical flag is set, then required as a hard rule with CPO selecting Microfibre or 3D Breathable fabric), closure (auto-selected by fabrication method), pathology classification (positional/synostotic with 11 variants — informs the CPO's shell design, does not drive configurator conditionals), clinical flags (hemangioma, atopic dermatitis, drainage, scar, birthmarks, glasses), device preview, and treatment phase with monthly progress reviews reflect clinical practice Clinical accuracy spot-check J8 - data-only, requires CO sign-off AC-CTE-108 Component Trees [CO] Cheneau TLSO: pressure zones, curve classification input, pad positioning — reflects scoliosis brace clinical practice Clinical accuracy spot-check J8 - data-only, requires CO sign-off
Open spec issues on GitHub
#302 critical spec: define AC-INF area - demo environment, seeded data, demo orgs/users domengabrovsek #301 critical spec: define AC-CMP area - audit trail centralisation, traceability export, retention domengabrovsek #300 critical spec: define AC-INV area - inventory, materials, purchase orders domengabrovsek #299 critical spec: define AC-PROD area - production workflows, work orders, quality control, delivery domengabrovsek #399 high spec: clarify 9 ambiguous component-tree ACs (AC-CTE-015/025/029/055/061/062/087/090/101) domengabrovsek #308 high spec: define AC-ORG-037 notification defaults matrix (roles x categories) domengabrovsek #307 high spec: clarify AC-ORG-030 - should invitation email list all assigned units or just primary? domengabrovsek #446 medium Spec gap — device-type change/override flow at the configurator is underspecified Sahtair #518 [post-Leipzig] Add `Closure Location` (Left/Right) attribute to Closure node spec for unilateral closures boltezar #517 [post-Leipzig] Spec the canonical Padding Thickness options for the Corrective Helmet configurator boltezar #516 [post-Leipzig] Reconcile `Forehead Asymmetry` field across spec, Figma, and implementation boltezar #514 [post-Leipzig] Reconcile CVAI severity scale across spec, Figma, and implementation boltezar #513 [post-Leipzig] Spec the alert copy for the clinical transparency-notice gate across patient + wizard pages boltezar #504 spec(component-trees): formal Global Component Category Registry — enumerate codes referenced by Contract #28 boltezar #498 Helmet fitting design (Figma 1178:76119) omits PROs - reconcile spec or design domengabrovsek #473 feat(organisation): formal Design Pattern Library spec + empty-library onboarding gate (post-Leipzig) boltezar #428 spec: define guardian removal workflow - AC-PAT-115 only covers "change", no rules for removing a non-primary / primary / last guardian Sahtair #309 spec: clarify AC-ORD-053 - warranty validation vs incident notification conflict domengabrovsek #303 spec: define AC-RPT area - normative hours and basic operational metrics domengabrovsek
DEP Dependency 12
Blocked by another AC or cross-module work
AC-ORG-162 Organisation [CPO] Data retention period of at least 10 years from last device placed on market is enforced Cross-org order retention not implemented AC-ORG-163 Organisation [CPO] No new patients, orders, or production work can be created under the terminated organisation Cross-org order retention not implemented AC-ORG-202 Organisation [CO] Measurement system preference (metric vs imperial) propagates to all clinical data entry points — limb measurements, segment lengths, range of motion values display consistently Measurement system propagation to clinical data entry depends on patient module AC-ORG-232 Organisation [CO] Technicians at any org type never see patient PII — only pseudonyms and fabrication-relevant clinical data Data minimisation depends on patient/order modules AC-ORG-233 Organisation [CPO] Billing Specialists see patient name, DOB, insurance, and pricing data — no clinical images, scans, or measurements Data minimisation depends on patient/order modules AC-ORG-235 Organisation [CO] Production Manager sees patient name + DOB on internal orders Data minimisation depends on patient/order modules AC-ORD-035 PARTIAL Orders & Configuration [CO] Bilateral flag creates L/R pair with mirror or independent configuration per AC-CTE-022 through AC-CTE-025; each side is independently editable when in independent mode. Bilateral handling applies to orthotic devices — prosthetic bilateral patients create two separate orders (one per side) per BR-PROS-006, because each residual limb has independent test socket iterations and completion timelines Bilateral L/R pair creation - depends on AC-CTE bilateral tested separately AC-ORD-009 READY Orders & Configuration [CPO] Component modifications during `FITTING` and FITTING are logged with what changed, clinical reasoning, timestamp, and user Component modification logging during fitting - depends on AC-ORD-036 action log persistence AC-ORD-039 Orders & Configuration [CO] The configurator can be reopened during `FITTING` and FITTING to swap components Depends on AC-ORD-038 AC-ORD-009 READY Orders & Configuration [CPO] Component modifications are logged with what changed, clinical reasoning, timestamp, and user Component modification logging during fitting - depends on AC-ORD-036 action log persistence AC-ORD-039 Orders & Configuration [CO] The configurator can be reopened during FITTING to swap components Depends on AC-ORD-038 AC-ORD-009 READY Orders & Configuration [CPO] Component modifications during FITTING are logged with what changed, clinical reasoning, timestamp, and user Component modification logging during fitting - depends on AC-ORD-036 action log persistence
BE Backend Not Implemented 43
AC-ORG-142 Organisation [CPO] Concurrent suspension: if two Org Admins each attempt to suspend the other simultaneously, at least one must remain active — one operation succeeds, the other is rejected Suspension edge cases not verified AC-ORG-161 Organisation [CO] Clinical records (visits, prescriptions, device configurations, fitting notes) created by the terminated organisation are retained and identifiable — for MDR audit response Data retention enforcement not implemented AC-ORG-167 Organisation [CPO] Deactivated units within the terminated organisation retain their data alongside the organisation's data Post-termination data retention not verified AC-ORG-168 Organisation [CO] Retention clock is per MDR Article 10(8) requirements — records must be accessible for the full retention period regardless of when termination occurred Post-termination data retention not verified AC-ORG-237 Organisation [CPO] Units cannot be deleted if they have associated orders or patients — deactivate instead Unit deletion constraints with orders not verified AC-PAT-323 Patients [CPO] Insurance information (health insurance card number and insurance provider — e.g., KZZ number and ZZZS in Slovenia) is required when a Reimbursement Prescription (naročilnica) is created for the order — the system checks payer validity before the CPO invests in fabrication. For self-paying patients (Path D), no Reimbursement Prescription is needed — self-pay is marked explicitly Insurance required for Reimbursement Prescription - cross-module gate not verified AC-PAT-328 Patients [CPO] When an order in DRAFT, AWAITING_PRESCRIPTION, or READY_FOR_PRODUCTION is cancelled, the order's Clinical Prescription and Reimbursement Prescription are hard-deleted along with the rest of the order's substantive content. A new order requires its own newly-issued prescriptions Cancelled order releases prescription - BE behaviour AC-PAT-109 Patients [CPO] If no patient information record exists, the system prompts — but does not block upload Upload without transparency warning - not verified AC-PAT-120 PARTIAL Patients [BOTH] Annex XIII Section 1 statement generated at fitting/delivery — frozen after generation Annex XIII Section 1 generation - not implemented AC-PAT-356 Patients [CPO] Clinical Prescription expires while visit is in Draft: visit completion is allowed, but "Send to Production" is blocked. Prescription validity is checked at the moment "Send to Production" is clicked — if the prescription's expiration date is today, the click succeeds (expiry means "before today," not "before this moment") Prescription expires during draft visit - submission blocking not verified AC-PAT-113 Patients [CO] Guardian-reported outcomes replace clinician-rated device outcomes for the infant Guardian-reported outcomes for infants - not verified AC-PAT-357 PARTIAL Patients [CPO] Device Delivery does NOT close the order — this is the start of treatment, not the end Device Delivery does not close order - BE lifecycle AC-PAT-120 PARTIAL Patients [BOTH] Annex XIII Section 1 statement generated at device delivery — frozen after generation Annex XIII Section 1 generation - not implemented AC-PAT-121 PARTIAL Patients [BOTH] Post-delivery adjustments are part of Annex XIII Section 2 documentation (living document), NOT the Section 1 statement Annex XIII Section 2 tracking - not implemented AC-PAT-086 Patients [CO] Cranial measurements captured and comparable to baseline for tracking progress Treatment monitoring - not fully verified AC-PAT-087 Patients [CO] Treatment timeline indicates which visits have scan data attached Treatment timeline scan data indicator - not verified AC-PAT-083 Patients [CPO] Only one Progress Review per order can be marked "treatment complete" Treatment completion signal - gate completion not verified in detail AC-PAT-122 PARTIAL Patients [BOTH] The completion check at order completion verifies: Section 1 was already generated at delivery, Section 2 documentation is complete (all Progress Reviews, adjustments, treatment completion) Completion-check Annex XIII verification - not implemented AC-PAT-084 Patients [CPO] Treatment completion is final for v1. Reversal with approval is a future capability Treatment monitoring - not fully verified AC-PAT-115 Patients [CPO] Guardian change during treatment: new guardian added, previous preserved in history Guardian change during treatment - not verified AC-PAT-120 PARTIAL Patients [BOTH] Annex XIII Section 1 statement generated at fitting/delivery — frozen after generation Annex XIII Section 1 generation - not implemented AC-PAT-368 Patients [CO] No hard limit on test socket iterations No hard limit on test socket iterations - server guarantee AC-PAT-106 Patients [CPO] Attachments cannot be hard-deleted — only soft-deleted/archived Attachment body region metadata - not verified AC-PAT-107 Patients [CPO] Attachments on orders that produced a placed-on-market device retained for minimum 10 years (MDR Art 10(8)). Consultation-only attachments deleted with the patient record Attachment body region metadata - not verified AC-PAT-108 Patients [CPO] Technicians access an order's attachments only by opening the order — no direct browsing of the patient record Attachment linking - not verified AC-PAT-120 PARTIAL Patients [BOTH] Annex XIII Section 1 statement (point-in-time) generated at fitting/delivery for all devices. Frozen after generation Annex XIII Section 1 generation - not implemented AC-PAT-121 PARTIAL Patients [BOTH] Post-delivery adjustments and treatment monitoring are Annex XIII Section 2 documentation (living document), not Section 1 Annex XIII Section 2 tracking - not implemented AC-PAT-122 PARTIAL Patients [BOTH] For devices with a treatment phase: Section 1 readiness checkpoint at FITTING → IN_TREATMENT. The completion check at IN_TREATMENT → COMPLETE verifies Section 1 was already generated and Section 2 is complete Completion-check Annex XIII verification - not implemented AC-PAT-123 Patients [BOTH] Complete device record (Section 1 + Section 2 + adjustment history) retained for minimum 10 years from the date the device was placed on the market (which for custom-made devices = delivery to patient). Note: 15-year retention applies for implantable custom-made devices per MDR Article 10(8) 10-year retention enforcement - not implemented AC-ORD-138 Orders & Configuration [CPO] Proceeding to configuration is blocked if the Initial Evaluation is currently being edited by another user — the CPO sees a message indicating the visit has unsaved changes. Proceeding is permitted only from a saved (Draft or Complete) visit Concurrent editing block on assessment - not verified AC-ORD-076 Orders & Configuration [CPO] All Annex XIII required fields are present in the order data model Annex XIII required fields in order data model - BE schema verification needed AC-ORD-114 Orders & Configuration [CPO] The payment path transitions from D (self-pay) to A or B (insurance covers fully or partially). For D→A: prepayment returned — amount, timestamp, user, and reason recorded. For D→B on AWAITING_PRESCRIPTION orders: production continues, `patientInformed` re-capture becomes a fitting prerequisite Treatment phase monitoring - not fully verified AC-ORD-084 Orders & Configuration [CO] The platform generates a Path C proposal document from existing order data — no separate data entry Payment path logic - not fully verified AC-ORD-076 Orders & Configuration [CPO] All Annex XIII required fields are present in the order data model Annex XIII required fields in order data model - BE schema verification needed AC-ORD-041 Orders & Configuration [CO] Clinical validity issues trigger soft warnings with override capability Clinical-validity soft warning + override flow at the DRAFT → AWAITING_PRESCRIPTION transition needs a full configurator-submission e2e test with a seeded clinical rule (tree engine already surfaces SOFT_WARNING, consumer path not pinned) AC-ORD-043 Orders & Configuration [CO] Material conflicts (allergies) trigger soft warnings with override — not hard blocks Material-allergy conflict detection requires catalog material metadata and a patient-flag -> material mapping that is not yet implemented AC-ORD-042 Orders & Configuration [CO] Mechanical compatibility violations trigger hard blocks with no override Path C payer approval workflow - not implemented AC-ORD-040 Orders & Configuration [CO] Required components missing triggers a hard block preventing submission Art 14 transparency for non-standard devices - not implemented AC-ORD-044 Orders & Configuration [BOTH] Every override requires a justification and is logged with timestamp and user Override justification is captured (overridesDocumented) but no e2e test asserts that a submission writes an order_gate_evidence row with user + timestamp + justification AC-ORD-045 Orders & Configuration [CPO] Override records are append-only and cannot be edited or deleted order_gate_evidence schema comment declares append-only and no UPDATE/DELETE path exists in code, but no test pins this invariant (needs either a DB-level constraint/trigger or an integration test asserting service code has no update path) AC-ORD-038 PARTIAL Orders & Configuration [CO] The configurator works for device types with and without encoded component trees Free-form entry for unlisted products - not verified AC-ORD-114 Orders & Configuration [CPO] Status change notifications are sent to the correct recipients per the notification table Treatment phase monitoring - not fully verified AC-ORD-029 PARTIAL Orders & Configuration [CPO] MDR-critical status transitions require mandatory notes documenting the clinical decision rationale MDR-critical status transitions (REJECTED, CANCELLED after SHIPPED, and related) do not yet enforce mandatory non-empty notes at the service layer - the notes column accepts updates but there is no conditional-on-transition validator
FE Frontend Not Implemented 32
AC-ORG-025 READY Organisation [CPO] No sections are shown that do not apply to this organisation type Org-type-specific section hiding - not fully verified AC-ORG-032 READY Organisation [CPO] Org Admin can assign all unit-role pairs in a single invitation flow Multi-unit-role invitation flow - not fully verified AC-ORG-043 PARTIAL Organisation [CPO] A user clicks an invitation link after 7 days. They see a clear error explaining the invitation has expired and should contact their Org Admin Expired invitation error message - not verified AC-ORG-044 READY Organisation [CPO] Org Admin resends an invitation from user management — resending invalidates any previous invitation link Resend invitation invalidates previous - not verified AC-PAT-324 Patients [CPO] Shipping address is required before device delivery — prompted at delivery, not at creation Shipping address required at delivery - FE prompt not implemented AC-PAT-340 Patients [CPO] When a patient arrives at reception, the admin can check in Pentla whether the patient information and consent form was signed digitally before the appointment. If signed → proceed to appointment. If not → admin gives paper form at reception Front Desk checks digital signature status - FE not implemented AC-PAT-343 Patients [CPO] Reimbursement Prescription (naročilnica) requires: health insurance card number, insurance provider, cost estimate, reference to Clinical Prescription, uploaded document. Only needed for insured patients (Paths A, B, C) Reimbursement Prescription required fields - not fully verified AC-PAT-345 Patients [CO] For returning patients, previous measurements are visible alongside new measurements Previous measurements visible alongside new - FE display not verified AC-PAT-347 Patients [CO] The justification becomes part of the visit record Field unavailability justification becomes part of visit record - no UI AC-PAT-348 Patients [CPO] Visit with documented field unavailability is valid for order creation Visit with field unavailability valid for order creation - not verified AC-PAT-351 Patients [CO] CPO performs delivery examination: fit verification, alignment check, skin check, functional test, patient/caregiver education (donning/doffing, wear schedule, skin care), delivery checklist (all components present, device matches configuration) Delivery examination structured fields - not fully implemented AC-PAT-354 Patients [CO] CPO performs follow-up examination: device fit, skin condition under device, wear pattern (pressure marks, redness), functional performance, alignment Follow-up examination structured fields - not fully implemented AC-PAT-358 Patients [CPO] Progress Reviews numbered sequentially per order (1, 2, 3...) Advanced clinical scenario - not verified AC-PAT-359 Patients [CPO] Treatment completion signals the Orders module to close the order. If the completion check passes, the order moves to COMPLETE and the CPO sees confirmation. If the completion check fails, the CPO sees the failure results with actionable items — they do not need to navigate to the Orders area separately to retry the transition Advanced clinical scenario - not verified AC-PAT-360 Patients [CPO] Attempting treatment complete on a second Progress Review for the same order is blocked Advanced clinical scenario - not verified AC-PAT-361 Patients [CO] Visit saved as Draft if infant is uncooperative — CPO completes later Advanced clinical scenario - not verified AC-PAT-362 Patients [CO] No maximum limit on number of Progress Reviews or treatment duration Advanced clinical scenario - not verified AC-PAT-345 Patients [CO] Previous measurements visible alongside new measurements Previous measurements visible alongside new - FE display not verified AC-PAT-363 Patients [CO] Prosthetic Initial Evaluation minimum fields include side and K-level in addition to standard minimums (amputation level is the picker's Subcategory and is not re-asked in the IE) Advanced clinical scenario - not verified AC-PAT-364 Patients [CO] CO documents socket fit findings: pressure distribution, alignment, suspension adequacy, gait observation, patient-reported comfort Advanced clinical scenario - not verified AC-PAT-365 Patients [CPO] New test socket fabrication cycle begins within the same order — iteration increments to "Test Socket 2" Advanced clinical scenario - not verified AC-PAT-366 Patients [CO] CO documents the clinical reasoning for the rebuild decision — what was wrong with the previous socket and what needs to change Advanced clinical scenario - not verified AC-PAT-364 Patients [CO] Socket fit findings documented across four evaluation stages. Each test socket iteration is represented by a Trial Fitting record with Visit A (fit-and-dispense — in-clinic seated, standing, brief dynamic, pre-dispatch post-removal inspection) and Visit B (review-after-trial — patient-reported wear experience, in-clinic examination while wearing, extended ambulation, cumulative post-removal skin inspection). The four stages at Visit A and Visit B examine different clinical content despite the shared naming. Findings include pressure distribution, alignment, suspension, gait observation, hyperemia assessment, and cumulative skin integrity trend. The definitive socket is fabricated based on the accepted test socket. See Patients Task 07 for the full Visit A / Visit B model. Advanced clinical scenario - not verified AC-PAT-351 Patients [CO] CO performs delivery examination: fit verification, alignment check, skin check, functional test, patient/caregiver education Delivery examination structured fields - not fully implemented AC-PAT-345 Patients [CO] Previous measurements visible alongside new measurements Previous measurements visible alongside new - FE display not verified AC-PAT-367 Patients [CPO] Attempting "Proceed to definitive" after it was already set is blocked Advanced clinical scenario - not verified AC-PAT-345 Patients [CO] Previous measurements visible alongside new measurements for comparison Previous measurements visible alongside new - FE display not verified AC-PAT-361 Patients [CPO] When the CPO chooses to finalise, the system checks minimum required fields (BR-PAT-020). Missing fields are listed with two actions: 'Go to field' and 'Mark as clinically unavailable' (BR-PAT-027) Advanced clinical scenario - not verified AC-ORD-080 Orders & Configuration [CPO] Four payment paths (A, B, C, D) are supported and documented on the order Four payment paths (A/B/C/D) - schema exists but FE workflow incomplete AC-ORD-082 Orders & Configuration [CPO] Path C captures standard alternative, recommended device, clinical justification, and payer approval status Path C justification - FE not verified AC-ORD-083 Orders & Configuration [CPO] Path C requires external payer approval before the order can be submitted to production Path C payer approval - FE not verified AC-ORD-085 Orders & Configuration [CPO] CPO can record payer approval (with reference) or denial on a Path C order Approval/denial recording - FE not verified
DEFERRED Deferred (post-Leipzig) 9
Intentionally postponed - not a Leipzig concern
AC-ORG-230 PARTIAL Organisation [CPO] The only exception to tenant isolation is platform admin operations Cross-org exceptions not implemented (post-WHX) AC-ORD-097 Orders & Configuration [CPO] Path C approval expiry (`approvalValidUntil`) generates a soft warning at submission when expired — not a hard block. CPO can override with documented acknowledgement Path C approval expiry (approvalValidUntil) soft warning at submission - not implemented. Deferred past Leipzig - the demo uses Path A exclusively (OTW_LEIPZIG_PREPARATION_PLAN.md), so the expired-approval branch is not exercised live. Revisit post-Leipzig when Path B/C payment flows are built out. AC-ORD-097 Orders & Configuration [CPO] Transition evidence is append-only and cannot be modified Path C approval expiry (approvalValidUntil) soft warning at submission - not implemented. Deferred past Leipzig - the demo uses Path A exclusively (OTW_LEIPZIG_PREPARATION_PLAN.md), so the expired-approval branch is not exercised live. Revisit post-Leipzig when Path B/C payment flows are built out. AC-ORD-130 Orders & Configuration [CPO] Terminal order states are COMPLETE and CANCELLED. All other statuses are non-terminal. Cross-area checks (organisation termination per AC-ORG-152, unit deactivation per AC-ORG-068) use this definition to determine whether outstanding orders exist Cross-org B2B ordering - post-WHX, not implemented AC-ORD-131 Orders & Configuration [CPO] An order in a CPO-dependent status (FITTING, FITTING, IN_TREATMENT) can be progressed by any active CPO assigned to the same unit — not only the CPO who created the order Cross-org B2B ordering - post-WHX, not implemented AC-CTE-002 Component Trees [CO] All six device categories are structurally present in the hierarchy: Lower Limb Orthotic, Upper Limb Orthotic, Lower Limb Prosthetic, Upper Limb Prosthetic, Cranial, Spinal. Four categories have published trees at WHX (Lower Limb Orthotic, Lower Limb Prosthetic, Cranial, Spinal); Upper Limb Orthotic and Upper Limb Prosthetic are visible but have no published trees yet All 6 device categories structurally present - Upper Limb trees not published (post-WHX) AC-CTE-045 Component Trees [CO] Transtibial prosthesis variants (temporary, definitive, swimming, sports) are separate device configurations, each with its own tree — a patient may have multiple active prostheses for different stages or activities, ordered independently Subtype activity variants - not on Leipzig demo path AC-CTE-059 Component Trees [CPO] Test scenarios can be saved and replayed for regression testing (deferred) Test scenarios save/replay for regression testing - post-WHX AC-CTE-089 Component Trees [CPO] Catalog management shows usage statistics for entries (deferred) Catalog usage statistics - post-WHX
Status:
Area:
Note:
Legend
Status (deterministic, test-driven)
READY Both BE and FE E2E tests pass
PARTIAL One of BE or FE E2E tests passes
NOT READY No passing tests in either repo
Test Coverage
BE ✓ Passing e2e test in pentla-api (backend)
BE No passing backend test
FE ✓ Passing e2e test in pentla-frontend
FE No passing frontend test
BE-only / FE-only AC only requires one repo for ready status
Note Categories (informational)
BE Backend API code not yet implemented
FE Frontend UI/UX not yet built
INFRA Platform infrastructure missing
SPEC Needs product decision or spec clarification
DEFERRED Intentionally postponed (post-Leipzig)
DEP Blocked by another feature or cross-module dependency

Organisation

72 ready 83 partial 55 not ready 210 total
#1 New Custom Manufacturer Onboarding End-to-End 38/54 70%
Step 1 — Platform Admin opens organisation management and starts creating a new organisation
READY BE ✓ FE ✓ AC-ORG-001 [CPO] Required fields enforced: organisation type, legal name, country, primary contact email
READY BE ✓ FE ✓ AC-ORG-002 [CPO] All 4 in-scope organisation types are selectable: Custom Manufacturer, Central Fab, Integrated Clinic-Fab, Clinic
READY BE ✓ FE ✓ AC-ORG-003 [CPO] Select "Custom-Made Device Manufacturer" as the type
Step 2 — Platform Admin creates the first unit (Production Facility)
READY BE ✓ FE ✓ AC-ORG-004 [CPO] Unit requires: name, type, country, address, data residency region, and applicable regulations
READY BE ✓ FE ✓ AC-ORG-005 [CPO] All 4 unit types are available: Clinic, Production Facility, Office, Warehouse
READY BE ✓ FE ✓ AC-ORG-006 [CO] Regulatory configuration and data residency region are auto-suggested based on unit country — e.g., Germany suggests MDR and GDPR with EU data residency
READY BE ✓ FE ✓ AC-ORG-007 [CPO] Data residency region is set at the unit level, not the organisation level. The org admin can adjust the auto-suggested region
READY BE ✓ FE ✓ AC-ORG-008 [CPO] Creating this first unit satisfies the requirement that an organisation must have at least one active unit
Step 3 — Platform Admin creates the first Org Admin user using the primary contact email
READY BE ✓ BE-only AC-ORG-009 [CPO] The first user is automatically assigned the Org Admin role
READY BE ✓ BE-only integration AC-ORG-010 [CPO] Invitation email is sent to the primary contact email
READY BE ✓ BE-only integration AC-ORG-011 [CPO] Invitation email includes or links to a privacy notice informing the staff user about data processing, lawful basis, retention, and their GDPR rights (Articles 13 and 15-22)
Step 4 — Platform Admin sets verification status and activates the organisation
READY BE ✓ FE ✓ AC-ORG-012 [CPO] Verification is a platform admin attribute on the organisation record — not a gate to access
READY BE ✓ FE ✓ AC-ORG-013 [CPO] Organisation transitions from Setup to Active
READY BE ✓ FE ✓ AC-ORG-014 [CPO] Org Admin cannot self-verify
Step 5 — Org Admin accepts the invitation, sets password, and logs in
PARTIAL BE FE ✓ AC-ORG-015 [CPO] Org Admin can set their password and access the platform once the organisation is Active
READY BE ✓ BE-only AC-ORG-016 [CPO] Platform loads with the Org Admin's primary unit as default context
READY FE ✓ FE-only AC-ORG-017 [CPO] On first login, Org Admin sees a welcome state with prompts to complete optional profile fields (trading name, addresses, logo) and invite team members. Incomplete fields are surfaced prominently but do not block platform use
Step 6 — Org Admin completes the organisation profile
READY BE ✓ FE ✓ AC-ORG-018 [CPO] Optional fields are editable: trading name, tax identifier, registration number, addresses, phone, website, logo
READY BE ✓ FE ✓ AC-ORG-019 [CPO] Organisation type is displayed but not editable by the Org Admin. A "Contact Support" action is available, pre-filled with the current type and reason for change request
READY BE ✓ FE ✓ AC-ORG-020 [CPO] Enabled areas are visible but changes require contacting sales
READY BE ✓ FE ✓ AC-ORG-021 [CPO] Changing the legal name saves immediately (no pending state). Org Admin sees confirmation that the change was saved and a note that Pentla may follow up. The platform admin is notified for potential re-verification. No access interruption
Step 7 — Org Admin configures organisation-wide preferences
READY BE ✓ FE ✓ AC-ORG-022 [CPO] All preferences configurable: measurement system, date format, time format, timezone, currency, language, locale
READY BE ✓ FE ✓ AC-ORG-023 [CO] Measurement system selection (metric vs imperial) is present and clearly labelled — this setting will propagate to all clinical measurement capture
Step 8 — Org Admin opens settings and sees sections appropriate for Custom Manufacturer
READY BE ✓ FE ✓ AC-ORG-024 [CPO] Visible sections: Organisation Profile, Units, Users and Roles, Preferences, Patient Settings, Production Settings, Order Settings, Notifications, Subscription and Billing
READY FE ✓ FE-only FE AC-ORG-025 [CPO] No sections are shown that do not apply to this organisation type
NOT READY AC-ORG-256 [CPO] The Org Admin can set the order reference number format in Order Settings. Editing the format affects only future orders — existing reference numbers are preserved
NOT READY AC-ORG-257 [CPO] The Org Admin can set the starting sequence value at onboarding so the platform continues the organisation's existing numbering. After the organisation has issued its first order reference, the starting value becomes view-only — adjusting it later requires Platform Admin involvement and a clear warning
NOT READY AC-ORG-258 [CPO] The current sequence value (the next number about to be issued) is visible in Order Settings so the Org Admin can monitor the organisation's running count
Step 9 — Org Admin invites team members: a CPO, a Production Manager, and a Technician
PARTIAL BE FE ✓ AC-ORG-026 [CPO] Role picker shows only roles available for Custom Manufacturer
PARTIAL BE FE ✓ AC-ORG-027 [CO] Clinician (CPO) role is available at Custom Manufacturer — correct, as CPOs at custom manufacturers assess patients and configure devices
READY BE ✓ FE ✓ AC-ORG-028 [CO] Physician role is NOT available at Custom Manufacturer — correct, as custom manufacturers receive prescriptions from external prescribers, they do not employ them
PARTIAL BE FE ✓ AC-ORG-029 [CPO] Each invited user must have at least one role assigned
READY BE ✓ FE ✓ AC-ORG-030 [CPO] Each invited user must be assigned to at least one unit
READY BE ✓ BE-only AC-ORG-031 [CPO] Each invited user must have exactly one primary unit
READY BE ✓ FE ✓ FE AC-ORG-032 [CPO] Org Admin can assign all unit-role pairs in a single invitation flow
READY BE ✓ FE ✓ AC-ORG-033 [CPO] Platform Admin role is not available in the role picker
READY BE ✓ BE-only integration AC-ORG-249 [CPO] Invitation email lists all assigned units with their roles and indicates which unit is primary
Step 10 — Org Admin enables notification preferences
READY BE ✓ FE ✓ AC-ORG-034 [CPO] Notification categories are visible: Orders, Production, Compliance, Billing, System
READY BE ✓ FE ✓ AC-ORG-035 [CPO] Notification preferences are per-user, not org-wide
READY BE ✓ FE ✓ AC-ORG-036 [CPO] Notification preferences are accessible from the user's own profile/account settings, not from the organisation settings area
PARTIAL BE FE ✓ AC-ORG-037 [CPO] Notification category defaults are role-aware — categories outside the user's area access default to OFF
Edge Cases
READY BE ✓ FE ✓ AC-ORG-038 [CPO] Attempting to create an organisation with a primary contact email already in use on the platform is rejected
READY BE ✓ FE ✓ AC-ORG-039 [CPO] Inviting a user with an email already in use on the platform is rejected with a clear error
NOT READY AC-ORG-254 [CPO] Email uniqueness is validated inline when the Platform Admin enters the primary contact email during org creation — the error appears before proceeding to unit and user setup
NOT READY AC-ORG-255 [CPO] If a duplicate email bypasses the invitation gate (race condition, direct data operation), the platform detects the ambiguity at login and blocks access until resolved — the user sees an error directing them to contact Pentla support. The incident is logged as a security event
NOT READY AC-ORG-040 [CO] Technician logs in and sees no patient PII anywhere — only pseudonymised references and fabrication data from the first moment they access the platform
READY BE ✓ FE ✓ AC-ORG-041 [CPO] Data retention minimum cannot be set below 10 years for organisations with MDR-applicable units
READY BE ✓ FE ✓ AC-ORG-042 [CPO] While the organisation is in Setup state (before activation), no patients or orders can be created — full platform access begins at Active
PARTIAL BE ✓ FE FE AC-ORG-043 [CPO] A user clicks an invitation link after 7 days. They see a clear error explaining the invitation has expired and should contact their Org Admin
READY BE ✓ FE ✓ FE AC-ORG-044 [CPO] Org Admin resends an invitation from user management — resending invalidates any previous invitation link
PARTIAL BE ✓ FE AC-ORG-045 [CPO] Attempting to submit the first order for a manufacturer org that has no registered or business address on file is blocked with a clear error citing Annex XIII requirements
NOT READY AC-ORG-046 [CPO] When a manufacturer organisation has no registered or business address on file, the dashboard and order creation surface a prominent prompt explaining the Annex XIII address requirement and linking to the organisation profile
PARTIAL BE ✓ FE AC-ORG-047 [CO] If a CPO reaches order submission without an address on file, the order can be saved as a draft — configuration work is not lost
PARTIAL BE FE ✓ AC-ORG-048 [CPO] If a user accepts an invitation while the organisation is still in Setup state, they can set their password but see a message explaining that the organisation is being set up and full platform access will begin once the Platform Admin activates it
#2 Multi-Unit Expansion and Role Assignment 3/24 13%
Step 1 — Org Admin views the current single-unit organisation's settings
PARTIAL BE FE ✓ AC-ORG-050 [CPO] No separate "Units" section appears — unit information is shown within the Organisation Profile section
PARTIAL BE FE ✓ AC-ORG-051 [CPO] An "Add Location" action is available
Step 2 — Org Admin adds a second unit: a Clinic
READY BE ✓ FE ✓ AC-ORG-052 [CPO] Required fields enforced: name, type, country, address, data residency region, and applicable regulations
NOT READY AC-ORG-053 [CPO] Unit name must be unique within the organisation
PARTIAL BE FE ✓ AC-ORG-054 [CO] Regulatory configuration auto-suggested based on the new unit's country
PARTIAL BE FE ✓ AC-ORG-055 [CPO] The platform explains that unit management has moved to its own section. Existing settings are preserved — nothing changes silently
READY BE ✓ FE ✓ AC-ORG-056 [CPO] After saving, a dedicated "Units" section now appears in settings showing both units
Step 3 — Org Admin assigns the existing CPO to the new Clinic unit
NOT READY AC-ORG-057 [CPO] CPO can be assigned to multiple units with different roles at each
PARTIAL BE ✓ FE AC-ORG-058 [CO] CPO assigned to the Clinic unit now has access to the clinical workflow — patient intake, visit creation, measurement capture, device configuration
NOT READY AC-ORG-059 [CPO] CPO's primary unit can be changed to the new Clinic unit
Step 4 — Org Admin assigns a Technician to the Production Facility only
NOT READY AC-ORG-060 [CPO] Technician is assigned to the Production Facility unit
NOT READY AC-ORG-061 [CO] Technician sees fabrication data and pseudonymised patient references only — no PII regardless of which unit they are assigned to
Step 5 — Org Admin views the user list and verifies unit assignments
READY BE ✓ FE ✓ AC-ORG-062 [CPO] Each user shows their assigned units and roles per unit
PARTIAL BE FE ✓ AC-ORG-063 [CPO] Org Admin (org-level role) automatically applies to all units — no per-unit assignment needed
Edge Cases
PARTIAL BE FE ✓ AC-ORG-064 [CPO] Attempting to add a unit with the same name as the existing unit is rejected
NOT READY AC-ORG-065 [CPO] A user with multiple roles across units sees a single unified interface — permissions are the union of all assigned roles, no role-switching
NOT READY AC-ORG-066 [CO] A CPO assigned to both a Clinic unit and a Production Facility unit can perform clinical workflows at the Clinic and make clinical sign-off decisions at the Production Facility — but cannot manage the production queue or assign work unless they also hold the Production Manager role
NOT READY AC-ORG-067 [CPO] Deactivating a unit that is a user's primary unit prompts reassignment of the user's primary unit to another active unit
NOT READY AC-ORG-068 [CPO] Deactivating a unit is blocked if it has in-progress internal orders. The platform shows the specific reason and count of affected orders
NOT READY AC-ORG-069 [CPO] Deactivating a unit is blocked if any users have it as their only unit assignment. The platform shows which users would be affected and guidance to reassign them first
NOT READY AC-ORG-070 [CPO] Attempting to deactivate the last active unit is blocked with a clear error
PARTIAL BE ✓ FE AC-ORG-071 [CPO] Deactivated units can be reactivated by the Org Admin — associated data becomes operational again
PARTIAL BE ✓ FE AC-ORG-072 [CO] A CPO assigned to two clinic units sees a persistent unit context indicator showing their current unit and can switch to their other unit without navigating to settings
PARTIAL BE ✓ FE AC-ORG-073 [CPO] After switching unit context, orders, patients, and production data filter to the selected unit. Organisation-level data (settings, subscription) remains unaffected
#3 Role-Based Access Verification Across Org Types 5/31 16%
Step 1 — Log in as a CPO at a Custom Manufacturer
READY BE ✓ FE ✓ AC-ORG-080 [CO] CPO has full access to Patients, Orders, and Configuration areas
NOT READY AC-ORG-081 [CO] CPO has clinical sign-off authority in Production — can view production status, evaluate test sockets, and accept or reject devices at fitting
PARTIAL BE FE ✓ AC-ORG-082 [CO] CPO cannot manage the production queue or assign work to technicians — that remains the Production Manager's responsibility
READY BE ✓ FE ✓ AC-ORG-083 [CO] CPO has no access to Compliance, Billing, or Settings (beyond own preferences)
READY BE ✓ FE ✓ AC-ORG-084 [CO] Navigation shows only accessible areas — inaccessible areas are hidden, not greyed out
Step 2 — Log in as a CPO at an Integrated Clinic-Fab
PARTIAL BE ✓ FE AC-ORG-085 [CO] CPO has the same capabilities as at a Custom Manufacturer — Patients, Orders, Configuration, and clinical sign-off authority in Production
PARTIAL BE FE ✓ AC-ORG-086 [CO] The difference from Custom Manufacturer is visible in the workflow: prescriptions are created by in-house Physicians, not received from external prescribers
Step 3 — Log in as a Physician at a Clinic (Prescribing Only)
NOT READY AC-ORG-087 [CO] Physician has full Patients access and Create + Read Orders access — they can create orders and see order status and outcomes for prescriptions they initiated
PARTIAL BE ✓ FE AC-ORG-088 [CO] Physician can create prescriptions. At organisation types where Physician role is unavailable (Custom Manufacturer, Central Fab), the Clinician role has prescribing authority where the unit's jurisdiction permits
PARTIAL BE FE ✓ AC-ORG-089 [CO] Physician cannot see orders they did not prescribe
PARTIAL BE FE ✓ AC-ORG-090 [CO] Physician has no access to Configuration at the component level — physicians prescribe device type and clinical indication; the CPO determines component-level specification
Step 4 — Log in as an Admin at a Custom Manufacturer
PARTIAL BE ✓ FE AC-ORG-091 [CO] Admin can enter data from a paper prescription (prescription intake — a clerical task)
READY BE ✓ FE ✓ AC-ORG-092 [CO] Admin cannot create a prescription as a clinical act — only Physician or Clinician (where jurisdiction permits) can
PARTIAL BE FE ✓ AC-ORG-093 [CO] Admin cannot access clinical visit fields or the device configurator
NOT READY AC-ORG-094 [CPO] Admin has patient demographics and order status access
Step 5 — Log in as a Production Manager at a Custom Manufacturer
PARTIAL BE FE ✓ AC-ORG-095 [CO] Production Manager sees patient name and date of birth on internal orders
NOT READY AC-ORG-097 [CPO] Production Manager can manage the production queue, assign work, and verify production phase completion
NOT READY AC-ORG-246 [CPO] Production Manager can create repair and maintenance orders
Step 6 — Log in as a Technician at a Custom Manufacturer
PARTIAL BE FE ✓ AC-ORG-098 [CO] Technician sees patient pseudonyms only — no name, date of birth, address, contact information, insurance details, or clinical visit notes on any screen
PARTIAL BE ✓ FE AC-ORG-099 [CPO] Technician can view fabrication data and update production status
PARTIAL BE ✓ FE AC-ORG-100 [CPO] Technician cannot access Patients area, Billing, Compliance, or Settings
Step 7 — Log in as a Billing Specialist at a Custom Manufacturer
NOT READY AC-ORG-101 [CPO] Billing Specialist sees patient name, DOB, insurance coverage, diagnosis codes, and device codes — for claim matching
PARTIAL BE FE ✓ AC-ORG-102 [CO] Billing Specialist cannot see clinical visit details, patient images, range of motion measurements, or clinical justification notes
Step 8 — Log in as an Org Admin and navigate to Settings at a Clinic (Prescribing Only)
PARTIAL BE FE ✓ AC-ORG-103 [CPO] Settings shows: Organisation Profile, Units, Users and Roles, Preferences, Patient Settings, Order Settings, Notifications, Subscription and Billing
PARTIAL BE FE ✓ AC-ORG-104 [CPO] Production Settings section is hidden — Clinics do not fabricate
Step 9 — Log in as an Org Admin and navigate to Settings at a Central Fab
PARTIAL BE FE ✓ AC-ORG-105 [CPO] Settings shows: Organisation Profile, Units, Users and Roles, Preferences, Production Settings, Order Settings, Notifications, Subscription and Billing
PARTIAL BE FE ✓ AC-ORG-106 [CPO] Patient Settings section is hidden — Central Fabs do not hold patient records
Edge Cases
NOT READY AC-ORG-107 [CPO] A user with both Org Admin and Clinician roles can access all areas (union of permissions). Prescribing authority follows BR-ORG-029: Physician always, Clinician where jurisdiction permits
PARTIAL BE FE ✓ AC-ORG-108 [CPO] Physician role is not available at Custom Manufacturer or Central Fab org types
PARTIAL BE FE ✓ AC-ORG-109 [CPO] Technician and Production Manager roles are not available at Clinic (Prescribing Only) org type
READY BE ✓ FE ✓ AC-ORG-111 [CO] When inviting or editing a user with the Physician role, credential fields are available: professional licence number, qualification/specialty, licensing authority. These pre-populate prescription records per Annex XIII
#4 User Suspension, Reactivation, and Org Admin Protection 8/25 32%
Step 1 — Org Admin navigates to User Management and selects a user to suspend
PARTIAL BE FE ✓ AC-ORG-120 [CPO] Suspension action is available for active users
READY BE ✓ FE ✓ AC-ORG-121 [CPO] Users cannot be deleted — only suspended. Verify that no "Delete" action exists
Step 2 — Org Admin suspends a CPO who has active clinical history (visits, orders, fittings)
PARTIAL BE ✓ FE AC-ORG-122 [CPO] Suspended user's state changes to Suspended
PARTIAL BE ✓ FE AC-ORG-123 [CPO] Suspended user cannot log in
NOT READY AC-ORG-124 [CO] Every visit the suspended CPO conducted still shows their name — verifiable by opening a patient record they worked on
NOT READY AC-ORG-125 [CO] Every order the suspended CPO configured still shows their name in the order history
NOT READY AC-ORG-126 [CO] Every clinical decision the suspended CPO approved (test socket evaluations, fitting acceptances) still shows their name in the audit trail — this is essential for MDR compliance
Step 3 — Org Admin reactivates the suspended CPO
READY BE ✓ FE ✓ AC-ORG-127 [CPO] Reactivation action is available for suspended users
PARTIAL BE ✓ FE AC-ORG-128 [CPO] User state changes from Suspended to Active
PARTIAL BE ✓ FE AC-ORG-129 [CPO] Reactivated user can log in again
PARTIAL BE ✓ FE AC-ORG-130 [CPO] All previous role and unit assignments are restored
NOT READY AC-ORG-131 [CPO] The suspension period is recorded in the audit log
Step 4 — Org Admin attempts to suspend the other Org Admin (leaving only themselves)
READY BE ✓ FE ✓ AC-ORG-132 [CPO] The action succeeds — the suspending Org Admin is now the last one, but the check is at the point of action, not a static invariant
Step 5 — The remaining Org Admin attempts to remove their own Org Admin role
READY BE ✓ FE ✓ AC-ORG-133 [CPO] The action is blocked — at least one active user with Org Admin role must exist per organisation
PARTIAL BE FE ✓ AC-ORG-134 [CPO] A clear error message explains why the action was blocked
Step 6 — The remaining Org Admin attempts to suspend their own account
READY BE ✓ FE ✓ AC-ORG-135 [CPO] The action is blocked — an Org Admin cannot suspend their own account if they are the last active Org Admin
PARTIAL BE FE ✓ AC-ORG-136 [CPO] A clear error message explains why the action was blocked
Step 7 — Org Admin views suspended users in the user list
READY BE ✓ FE ✓ AC-ORG-137 [CPO] Suspended users are visible in the user list with a clear "Suspended" status
READY BE ✓ FE ✓ AC-ORG-138 [CPO] Suspended users' role assignments and unit assignments are preserved and visible
Edge Cases
PARTIAL BE ✓ FE AC-ORG-139 [CO] A suspended Physician's existing prescriptions remain valid and linked to orders — suspending the prescriber on the platform does not invalidate the prescription
READY BE ✓ BE-only AC-ORG-140 [CPO] Inviting a user with the same email as a suspended user within the same org is blocked — the system directs the Org Admin to reactivate the user from User Management instead
PARTIAL BE ✓ FE AC-ORG-141 [CPO] If a user is suspended while in the Invited state (before accepting), the invitation link is invalidated
NOT READY BE AC-ORG-142 [CPO] Concurrent suspension: if two Org Admins each attempt to suspend the other simultaneously, at least one must remain active — one operation succeeds, the other is rejected
PARTIAL BE FE ✓ AC-ORG-143 [CPO] When suspending a CPO, if that CPO has orders in CPO-dependent statuses (FITTING, TEST\_DEVICE\_FITTING, IN\_TREATMENT), the suspension confirmation shows the count and list of affected orders. Suspension proceeds — the system does not block — but the Org Admin is informed that another CPO at the same unit must continue these orders
PARTIAL BE FE ✓ AC-ORG-144 [CPO] Removing the Clinician (CPO) role from a user is blocked if they are the only active CPO at a unit that has orders in CPO-dependent statuses (FITTING, TEST\_DEVICE\_FITTING, IN\_TREATMENT). The error message lists the affected orders and directs the Org Admin to assign another CPO to the unit first
#5 Organisation Termination and Data Retention 0/19 0%
Step 1 — Platform Admin opens an active organisation's detail page
PARTIAL BE FE ✓ AC-ORG-150 [CPO] Organisation shows current state: Active
PARTIAL BE FE ✓ AC-ORG-151 [CPO] Verification status is visible as a platform admin attribute
Step 2 — Platform Admin attempts to terminate the organisation while orders are in non-terminal states
PARTIAL BE FE ✓ AC-ORG-152 [CPO] Termination is blocked — the platform shows a summary of outstanding orders in non-terminal states
PARTIAL BE FE ✓ AC-ORG-153 [CPO] The platform provides guidance on what must happen before termination can proceed (orders must be completed or cancelled)
Step 3 — After resolving outstanding orders, Platform Admin initiates termination
PARTIAL BE FE ✓ AC-ORG-154 [CPO] Termination requires explicit confirmation — not a single-click action
PARTIAL BE FE ✓ AC-ORG-155 [BOTH] Termination is irreversible — the confirmation makes this clear
Step 4 — After termination, verify the organisation is in Terminated state
PARTIAL BE FE ✓ AC-ORG-156 [CPO] Organisation state is Terminated — no transition back to Active is possible
PARTIAL BE ✓ FE AC-ORG-157 [CPO] No user of the terminated organisation can log in
NOT READY AC-ORG-158 [CPO] All data is retained per MDR requirements
PARTIAL BE ✓ FE AC-ORG-159 [CPO] All pending invitations are invalidated
Step 5 — Verify data retention and accessibility
PARTIAL BE FE ✓ AC-ORG-160 [CPO] Platform Admin can still view the terminated organisation's records for regulatory compliance purposes
NOT READY BE AC-ORG-161 [CO] Clinical records (visits, prescriptions, device configurations, fitting notes) created by the terminated organisation are retained and identifiable — for MDR audit response
NOT READY DEP AC-ORG-162 [CPO] Data retention period of at least 10 years from last device placed on market is enforced
Step 6 — Verify no operational actions are possible
NOT READY DEP AC-ORG-163 [CPO] No new patients, orders, or production work can be created under the terminated organisation
NOT READY AC-ORG-164 [CPO] No settings can be changed
Edge Cases
PARTIAL BE ✓ FE AC-ORG-165 [CPO] A user who had a pending invitation attempts to accept it after termination — they see a clear error explaining the organisation has been terminated
NOT READY BE AC-ORG-167 [CPO] Deactivated units within the terminated organisation retain their data alongside the organisation's data
NOT READY BE AC-ORG-168 [CO] Retention clock is per MDR Article 10(8) requirements — records must be accessible for the full retention period regardless of when termination occurred
PARTIAL BE FE ✓ AC-ORG-169 [CPO] When the termination blocking summary includes orders in IN\_TREATMENT (treatment phase orders that may run months or years), the guidance explicitly lists treatment completion or cancellation as the resolution path — Platform Admin is not given a mechanism to force-terminate while treatment orders remain active
#6 CPO Clinical Workflow — Cross-Area Role Verification 6/8 75%
Step 1 — CPO opens the Patients area
READY BE ✓ FE ✓ AC-ORG-180 [CO] CPO can view patient records and open a specific patient
Step 2 — CPO opens a visit for that patient
PARTIAL BE ✓ FE AC-ORG-181 [CO] CPO can view and create clinical visits — measurements, contraindications, clinical reasoning
Step 3 — CPO navigates to Orders and opens the device configurator
READY BE ✓ FE ✓ AC-ORG-182 [CO] CPO can configure a device by selecting components from the component catalog
PARTIAL BE ✓ FE AC-ORG-183 [CO] CPO can submit the order
Step 4 — CPO navigates to Production to check an order requiring clinical sign-off
READY BE ✓ FE ✓ AC-ORG-184 [CO] CPO can view production status for orders they submitted
READY BE ✓ FE ✓ AC-ORG-185 [CO] CPO can evaluate test sockets and accept or reject devices at fitting — clinical sign-off decisions in the production context
READY BE ✓ FE ✓ AC-ORG-186 [CO] CPO cannot assign work, reorder the queue, or perform production management actions
Step 5 — CPO navigates back to Orders to perform a fitting
READY BE ✓ FE ✓ AC-ORG-187 [CO] CPO can record fitting notes and delivery
⚙ Cross-Cutting Concerns 12/49 24%
Data Flow Verification
READY BE ✓ FE ✓ AC-ORG-200 [CPO] Organisation type correctly determines which platform areas are enabled — verify against the Area Access Matrix in ORGANISATION_TYPES.md for all 4 in-scope types
READY BE ✓ FE ✓ AC-ORG-201 [CPO] Organisation-wide preferences (measurement system, date format, timezone, currency) propagate as defaults to all users across the platform
NOT READY DEP AC-ORG-202 [CO] Measurement system preference (metric vs imperial) propagates to all clinical data entry points — limb measurements, segment lengths, range of motion values display consistently
READY BE ✓ FE ✓ AC-ORG-203 [CPO] Individual users can override locale and timezone for personal preference without affecting the organisation default. Users cannot override: measurement system, date format, time format, currency, language
NOT READY AC-ORG-204 [CPO] Preferences affect presentation only — stored data is not altered when preferences change
Role-Based Access Spot-Checks
READY BE ✓ FE ✓ AC-ORG-205 [CPO] Org Admin: full access to all settings, all areas, all units
READY BE ✓ FE ✓ AC-ORG-206 [CPO] Billing Admin: subscription, billing, and financial settings; view-only Compliance and Insights; no clinical or operational access
PARTIAL BE ✓ FE AC-ORG-207 [CO] Clinician (CPO): full Patients, Orders, Configuration; clinical sign-off authority in Production; no Compliance, Billing, or Settings
PARTIAL BE ✓ FE AC-ORG-208 [CO] Physician: full Patients; Create + Read Orders; no Configuration, Production, Compliance, Billing, or Settings
PARTIAL BE ✓ FE AC-ORG-209 [CPO] Admin: demographics, order status + logistics, prescription intake; no clinical visit, configuration, production, billing, or compliance
PARTIAL BE ✓ FE AC-ORG-210 [CPO] Production Manager: full Production; pseudonym-or-name patient access depending on order source; no Configuration, Compliance, or Billing
PARTIAL BE ✓ FE AC-ORG-211 [CPO] Technician: pseudonym only; fabrication data and status updates; no Patients, Billing, Compliance, or Settings
NOT READY AC-ORG-212 [CPO] Billing Specialist: insurance and pricing only; no clinical data
NOT READY AC-ORG-213 [CPO] Quality/Compliance Officer: read-only access to clinical data (measurements, scans, visit notes), device configurations, override records with justifications, snapshot correction field-level values (original and new), fitting adjustment records, and the full traceability chain. Can create compliance-layer records (flags, non-conformance observations, compliance holds) but cannot modify clinical or operational data. No access to patient PII (name, DOB, contact, insurance), pricing, or shipping address
PARTIAL BE ✓ FE AC-ORG-214 [CPO] Logistics: sees order references and shipping addresses only
Organisation Lifecycle State Enforcement
PARTIAL BE FE ✓ AC-ORG-215 [CPO] Setup to Active: only Platform Admin can trigger
PARTIAL BE FE ✓ AC-ORG-216 [CPO] Active to Terminated: only Platform Admin can trigger; irreversible
PARTIAL BE FE ✓ AC-ORG-217 [CPO] No other state transitions are possible (e.g., Active to Setup, Terminated to Active)
NOT READY AC-ORG-218 [CPO] While in Setup state, no patients or orders can be created
User Lifecycle State Enforcement
NOT READY AC-ORG-219 [CPO] Invited to Active: triggered when user accepts invitation and sets password
READY BE ✓ FE ✓ AC-ORG-220 [CPO] Active to Suspended: triggered by Org Admin
READY BE ✓ FE ✓ AC-ORG-221 [CPO] Suspended to Active: triggered by Org Admin reactivation. Suspension period recorded in audit log
READY BE ✓ FE ✓ AC-ORG-222 [CPO] Suspended users retain all data, role assignments, and unit assignments in read-only form
NOT READY SPEC AC-ORG-223 [CPO] Invitation expiry: links expire after a configurable window (default: 7 days). Resending invalidates previous links
Compliance and Audit Trail
NOT READY AC-ORG-224 [BOTH] Every modification to organisation data is logged: who changed what, when — including profile changes, role changes, unit changes, settings modifications
PARTIAL BE ✓ FE AC-ORG-225 [CPO] User PII (name, email, phone) is visible only to authorised roles within the same organisation
PARTIAL BE FE ✓ AC-ORG-226 [CPO] User PII is not exposed in system logs
PARTIAL BE FE ✓ AC-ORG-227 [CPO] Platform Admins see organisation-level data for verification only — not individual user PII
NOT READY AC-ORG-228 [CPO] At manufacturer organisations, one user with the Quality/Compliance Officer or Org Admin role can optionally be designated as PRRC (Person Responsible for Regulatory Compliance, MDR Article 15). The flag is optional data capture, not a platform gate
Tenant Isolation
PARTIAL BE ✓ FE AC-ORG-229 [CPO] Organisation A's users, data, and settings are invisible to Organisation B — hard boundary
PARTIAL BE ✓ FE DEFERRED AC-ORG-230 [CPO] The only exception to tenant isolation is platform admin operations
NOT READY AC-ORG-250 [CPO] A user's session is bound to exactly one organisation, determined at login from their user record — there is no org selection screen or org switching
NOT READY AC-ORG-251 [CPO] Every request is scoped to the authenticated user's organisation before role-based or unit-based filtering — data from other organisations is never returned
NOT READY AC-ORG-252 [CPO] Requesting an entity by ID that belongs to a different organisation returns an authorisation error — the response does not reveal whether the entity exists
NOT READY AC-ORG-253 [CPO] Tenant isolation applies to all org-scoped entities: patients, orders, visits, attachments, prescriptions, component tree extensions, catalogue pricing overrides, users, units, settings, and audit logs
Data Minimisation
NOT READY DEP AC-ORG-232 [CO] Technicians at any org type never see patient PII — only pseudonyms and fabrication-relevant clinical data
NOT READY DEP AC-ORG-233 [CPO] Billing Specialists see patient name, DOB, insurance, and pricing data — no clinical images, scans, or measurements
PARTIAL BE ✓ FE AC-ORG-234 [CPO] Notifications contain order references only — no patient data in email or push notifications
NOT READY DEP AC-ORG-235 [CO] Production Manager sees patient name + DOB on internal orders
Deletion Constraints
READY BE ✓ FE ✓ AC-ORG-236 [CPO] Organisations cannot be hard-deleted — only terminated
NOT READY BE AC-ORG-237 [CPO] Units cannot be deleted if they have associated orders or patients — deactivate instead
NOT READY AC-ORG-238 [CPO] At least one unit must remain active per active organisation
READY BE ✓ FE ✓ AC-ORG-239 [CPO] Users cannot be deleted — only suspended
PARTIAL BE ✓ FE AC-ORG-240 [CPO] At least one active Org Admin must exist per active organisation
Concurrent Operations
PARTIAL BE ✓ FE AC-ORG-241 [CPO] When two authorised users edit the same setting concurrently, the second user is informed that the value has changed since they loaded the page and must refresh before saving
User Profile Access
PARTIAL BE FE ✓ AC-ORG-242 [CPO] Every user (regardless of role) can access their own profile from the platform header
PARTIAL BE FE ✓ AC-ORG-243 [CPO] Users can edit their job title, phone number, locale override, and timezone override from their profile
READY BE ✓ FE ✓ AC-ORG-244 [CO] Physicians can view and edit their credential fields (licence number, qualification, licensing authority) from their profile
READY BE ✓ FE ✓ AC-ORG-245 [CPO] Users can view their unit assignments, role assignments, and primary unit from their profile (read-only — changes require Org Admin)

Patients

19 ready 65 partial 230 not ready 314 total
#0 Patient Creation Scenarios 6/29 21%
Prerequisites
NOT READY AC-PAT-016 [CPO] Patient creation requires the organisation to be in Active state — blocked with explanatory message when organisation is in Setup or Terminated state
PARTIAL BE FE ✓ AC-PAT-321 [CPO] Patient creation requires assignment to an active unit — blocked if no active units exist
PARTIAL BE FE ✓ AC-PAT-322 [CPO] New patient's primary unit is auto-assigned from the user's active unit context *(AC-ORG-072, AC-ORG-073)* — no manual unit selection in the creation form. If a CPO needs to create a patient for a different unit, they switch unit context first (one action in the persistent header control), then create the patient
Mandatory and progressive fields
READY BE ✓ FE ✓ AC-PAT-001 [CPO] Patient record can be created with minimum fields: first name, last name, date of birth, phone number, email address
NOT READY BE AC-PAT-323 [CPO] Insurance information (health insurance card number and insurance provider — e.g., KZZ number and ZZZS in Slovenia) is required when a Reimbursement Prescription (naročilnica) is created for the order — the system checks payer validity before the CPO invests in fabrication. For self-paying patients (Path D), no Reimbursement Prescription is needed — self-pay is marked explicitly
NOT READY FE AC-PAT-324 [CPO] Shipping address is required before device delivery — prompted at delivery, not at creation
Draft orders without Clinical Prescription
READY BE ✓ FE ✓ AC-PAT-325 [CPO] A CPO can proceed from a visit to device configuration before the Clinical Prescription (izvid) is in the system. The order is created silently — the CPO begins clinical work without an explicit "create order" step
READY BE ✓ FE ✓ AC-PAT-326 [CPO] The draft order collects visit data, measurements, scans, and device configuration — all before the Clinical Prescription arrives
PARTIAL BE ✓ FE AC-PAT-327 [CPO] The order's "Send to Production" button stays disabled until a valid Clinical Prescription (izvid) has been uploaded against the order (for MDR-regulated orders). The Clinical Prescription is a release gate, not a creation prerequisite. For insured patients, a Reimbursement Prescription (naročilnica) is additionally required on the order before fabrication can begin
NOT READY BE AC-PAT-328 [CPO] When an order in DRAFT, AWAITING_PRESCRIPTION, or READY_FOR_PRODUCTION is cancelled, the order's Clinical Prescription and Reimbursement Prescription are hard-deleted along with the rest of the order's substantive content. A new order requires its own newly-issued prescriptions
NOT READY AC-PAT-206 [BOTH] Clinical and Reimbursement Prescriptions are uploaded directly into the relevant order's Medical Device Documents section by a CPO, Front Desk, or Org Admin. The order the prescription belongs to is determined by where it is uploaded — there is no platform-side matching of prescriptions to orders
NOT READY AC-PAT-207 [BOTH] Once a prescription is uploaded against an order, the CPO is notified that the order's prescription requirement has been met. The order is one step closer to being releasable but is not auto-released — releasing requires an explicit "Send to Production" click
PARTIAL BE FE ✓ AC-PAT-003 [CPO] Duplicate detection fires on name + DOB match — shows potential matches but does not block creation
READY BE ✓ FE ✓ AC-PAT-004 [CPO] Patient status starts as Active when the record is created
Path A and B — CPO in the field
PARTIAL BE FE ✓ AC-PAT-329 [CO] CPO can create a patient record and capture preliminary clinical notes, measurements, and photos in the field
PARTIAL BE FE ✓ AC-PAT-330 [CPO] When the patient later visits the clinic, admin can add insurance and other administrative data to the existing record
Path C and D — Front Desk creates, CPO continues
PARTIAL BE FE ✓ AC-PAT-331 [CPO] Front Desk can create a patient record with demographics and contact details. The CPO later opens the same record to add clinical data
PARTIAL BE FE ✓ AC-PAT-332 [CPO] Front Desk can enter the Clinical Prescription (izvid) and/or Reimbursement Prescription (naročilnica) at reception if the patient brings them
Path E and F — CPO creates directly in clinic
PARTIAL BE FE ✓ AC-PAT-333 [CO] CPO can create the patient record and proceed directly to clinical work without admin involvement
Transparency and consent per path
PARTIAL BE FE ✓ AC-PAT-334 [CPO] Both Front Desk and CPO roles can record the patient information acknowledgment. The record captures WHO informed the patient
PARTIAL BE FE ✓ AC-PAT-335 [CPO] The signed patient information form (patient information acknowledgment + non-clinical consents) must be scanned and uploaded to the patient record as a classified attachment type (distinct from clinical images and scans — aids audit retrieval)
READY FE ✓ FE-only AC-PAT-336 [CPO] Patient information is a soft prompt, not a hard block — clinical work can proceed if the patient information record hasn't been completed yet, but the system shows a persistent reminder
PARTIAL BE FE ✓ AC-PAT-337 [CPO] If a patient refuses to sign the form, the CPO records "patient was verbally informed, declined to sign" — the GDPR transparency obligation is met by informing the patient, not by obtaining their signature. Clinical work proceeds regardless
READY FE ✓ FE-only AC-PAT-338 [CPO] Non-clinical consent checkboxes on the form must default to unchecked — pre-ticked boxes are not valid consent under GDPR (Recital 32, CJEU Planet49)
PARTIAL BE FE ✓ AC-PAT-339 [CPO] Non-clinical consent (marketing, research) can be captured at any point — reception, during a visit, or at a later visit. It never blocks clinical actions
NOT READY FE AC-PAT-340 [CPO] When a patient arrives at reception, the admin can check in Pentla whether the patient information and consent form was signed digitally before the appointment. If signed → proceed to appointment. If not → admin gives paper form at reception
PARTIAL BE FE ✓ AC-PAT-341 [CPO] The patient information record distinguishes how it was signed: pre-appointment (digital), at reception (paper), or during visit (paper or verbal). All three satisfy GDPR transparency equally
Edge Cases
NOT READY AC-PAT-013 [CPO] Concurrent edit: if admin and CPO are both editing the same patient record, the second to save is informed and must refresh
PARTIAL BE FE ✓ AC-PAT-342 [CPO] Duplicate detection works the same regardless of who creates the record (admin or CPO) and where (field or clinic)
#1 New AFO Patient — End-to-End 5/46 11%
Step 1 — Patient record created (Journey 0)
Step 2 — Verify patient information and consent
PARTIAL BE FE ✓ AC-PAT-025 [CPO] Outstanding patient information items are visible on the patient record summary — none should remain before clinical work begins
READY BE ✓ FE ✓ AC-PAT-020 [CPO] Patient information record present with: timestamp, method, staff member identity
NOT READY be_implemented AC-PAT-021 [CO] Patient information record is informational — not a consent gate. Clinical processing continues under the treatment lawful basis (Article 9(2)(h))
Step 3 — Enter Clinical Prescription (izvid) and Reimbursement Prescription (naročilnica)
NOT READY AC-PAT-030 [CPO] Clinical Prescription (izvid) requires: prescriber name, qualification, licence number, institution, diagnosis (with ICD code), device authorised, laterality (left/right/bilateral — shown for lateralised devices; hidden for midline devices such as cranial helmets and spinal braces), prescription date, expiration date, uploaded document. Prescriptions can be created by users with prescribing authority: Physician role (always), or Clinician role where the unit's jurisdiction authorises CPO prescribing *(BR-ORG-029)*. Front Desk can record prescriber details and upload prescription documents from paper prescriptions — this is data entry of an external prescription, not the clinical act of prescribing
NOT READY FE AC-PAT-343 [CPO] Reimbursement Prescription (naročilnica) requires: health insurance card number, insurance provider, cost estimate, reference to Clinical Prescription, uploaded document. Only needed for insured patients (Paths A, B, C)
NOT READY AC-PAT-033 [CPO] Previously entered prescribers are suggested on name entry
PARTIAL BE FE ✓ AC-PAT-035 [CO] K-level field appears only for prosthetic Clinical Prescriptions — it is hidden for non-prosthetic device types (orthotics, cranial helmets, spinal braces)
NOT READY AC-PAT-032 [CPO] Clinical Prescriptions are immutable after creation — corrections supersede the original, which is preserved in the audit trail
Step 4 — Conduct Initial Evaluation
PARTIAL BE FE ✓ AC-PAT-040 [CPO] System verifies the patient record is in Active state before a visit can be started — if the patient is Inactive, reactivation is prompted
NOT READY AC-PAT-042 [CPO] Visit starts in Draft status
PARTIAL BE FE ✓ AC-PAT-045 [CO] For returning patients, medical history is pre-populated from the patient record and editable
NOT READY AC-PAT-344 [CO] Each measurement records: type, anatomical location, laterality (left/right/N/A), value, unit (per org settings), and condition (weight-bearing/non-weight-bearing/supine)
NOT READY FE AC-PAT-345 [CO] For returning patients, previous measurements are visible alongside new measurements
PARTIAL BE FE ✓ AC-PAT-050 [CO] Clinical reasoning fields present: assessment summary, treatment goals, device recommendation, special instructions
READY FE ✓ FE-only AC-PAT-346 [CO] Empty clinical reasoning triggers a warning but does NOT block completion
Step 5 — Mark a required field as clinically unavailable
PARTIAL BE FE ✓ AC-PAT-049 [CO] CPO can mark a required field as "clinically unavailable" with mandatory free-text justification
NOT READY FE AC-PAT-347 [CO] The justification becomes part of the visit record
NOT READY FE AC-PAT-348 [CPO] Visit with documented field unavailability is valid for order creation
Step 6 — Upload scan files and clinical images
PARTIAL BE FE ✓ AC-PAT-102 [CPO] Scan files (STL, OBJ, PLY, STEP) can be uploaded with metadata: body region, laterality, description
PARTIAL BE FE ✓ AC-PAT-103 [CPO] Clinical images (JPG, PNG, HEIC) can be uploaded
READY BE ✓ BE-only AC-PAT-104 [CPO] File integrity verified via checksum on upload
PARTIAL BE FE ✓ AC-PAT-105 [CPO] File size limits enforced per type (500 MB scan, 50 MB image)
NOT READY BE AC-PAT-109 [CPO] If no patient information record exists, the system prompts — but does not block upload
Step 7 — Complete Initial Evaluation and create order
PARTIAL BE FE ✓ AC-PAT-041 [CO] Minimum fields enforced for Initial Evaluation completion: weight, height, at least one measurement, contraindication review completed (either individual category review or a single 'no contraindications identified' confirmation covering all categories)
PARTIAL BE FE ✓ AC-PAT-043 [CPO] On completion, system records: CPO identity and completion timestamp
NOT READY AC-PAT-034 [CPO] Clinical Prescription (izvid) validity checked at "Send to Production" (not at order creation) — must be active, non-expired on the order. For insured patients, Reimbursement Prescription (naročilnica) must also be approved before fabrication begins. Draft orders can exist without either document per AC-PAT-325
Step 8 — Trial Fitting after fabrication
NOT READY AC-PAT-063 [CO] Trial Fitting visit can be created linked to the order
READY BE ✓ FE ✓ AC-PAT-349 [CO] Clinical Prescription is inherited from the order — not re-verified at each visit
READY BE ✓ FE ✓ AC-PAT-350 [CO] Iteration outcome field present with device-appropriate labels: Proceed to finishing / Rebuild / Adjust and refit / Discontinue (device approach not viable — requires clinical justification, cancels the order)
NOT READY AC-PAT-051 [CO] Any device adjustments recorded as distinct structured entries
NOT READY AC-PAT-052 [CPO] Adjustment records cannot be edited after creation — append-only. Soft delete for errors, original preserved
Step 9 — Device Delivery
NOT READY AC-PAT-064 [CPO] Device Delivery visit created with delivery confirmation
NOT READY FE AC-PAT-351 [CO] CPO performs delivery examination: fit verification, alignment check, skin check, functional test, patient/caregiver education (donning/doffing, wear schedule, skin care), delivery checklist (all components present, device matches configuration)
NOT READY AC-PAT-055 [CO] Clinician-rated device outcomes captured:
PARTIAL BE ✓ FE BE AC-PAT-120 [BOTH] Annex XIII Section 1 statement generated at fitting/delivery — frozen after generation
Step 10 — Post-delivery Follow-Up (2–4 weeks later)
NOT READY AC-PAT-069 [CO] Follow-Up visit can be created linked to the order (Slovenian: Kontrola po prevzemu)
PARTIAL BE ✓ FE AC-PAT-352 [CO] Follow-Up does not require a prescription
PARTIAL BE FE ✓ AC-PAT-353 [CO] Follow-Ups are numbered sequentially (Follow-Up 1, 2, 3...)
NOT READY FE AC-PAT-354 [CO] CPO performs follow-up examination: device fit, skin condition under device, wear pattern (pressure marks, redness), functional performance, alignment
NOT READY AC-PAT-051 [CO] Device adjustments can be recorded at follow-up visits (using IN-PAT-008 fields)
NOT READY AC-PAT-055 [CO] Clinician-rated device outcomes captured at follow-up
NOT READY AC-PAT-054 [CO] CPO indicates next steps after the visit
Edge Cases
NOT READY AC-PAT-070 [CO] Bilateral AFO: single visit with laterality-specific measurements → single bilateral order
NOT READY AC-PAT-355 [CPO] Clinical Prescription near expiration: system warns during the visit if it expires within 30 days
NOT READY BE AC-PAT-356 [CPO] Clinical Prescription expires while visit is in Draft: visit completion is allowed, but "Send to Production" is blocked. Prescription validity is checked at the moment "Send to Production" is clicked — if the prescription's expiration date is today, the click succeeds (expiry means "before today," not "before this moment")
NOT READY AC-PAT-071 [CPO] Full visit history visible for the order: Initial Evaluation, Trial Fitting(s), Device Delivery, Follow-Up(s), Service visits
#2 Corrective Helmet Treatment — Infant with Guardian 2/43 5%
Step 1 — Create infant patient record
PARTIAL BE FE ✓ AC-PAT-110 [CPO] Entering a DOB indicating a minor triggers a prompt for guardian information
PARTIAL BE FE ✓ AC-PAT-111 [CPO] Minor detection is calculated from DOB, not a manual flag
PARTIAL BE FE ✓ AC-PAT-112 [CPO] Multiple guardians can be entered (both parents), one marked as primary contact
Step 2 — Patient information and guardian consent
READY BE ✓ FE ✓ AC-PAT-024 [CPO] Consent record identifies the guardian as the consenting party, not the infant
PARTIAL BE FE ✓ AC-PAT-114 [CPO] Communication preferences default to the guardian's contact details
Step 3 — Consultation and cranial scan (most patients arrive without prescription)
PARTIAL BE FE ✓ AC-PAT-060 [CO] CPO creates a Consultation (no prescription required). Scans the infant, captures cranial measurements, evaluates severity
NOT READY be_implemented AC-PAT-116 [CPO] The scan report (a cranial scan PDF produced by the CPO's scanner software) is uploaded to Pentla. Pentla parses the PDF and extracts measurement data (CVAI, Cephalic Index, circumference, diagonals, severity) into the visit fields — CPO reviews and confirms, no manual re-entry. Parents take a copy of the report to the prescriber
NOT READY AC-PAT-053 [CO] Visit form adapts for the cranial helmet device type (both Consultation and Initial Evaluation)
NOT READY AC-PAT-062 [CO] CPO creates an Initial Evaluation. Consultation data (measurements, scan, clinical reasoning) carries forward into a reference panel — CPO reviews and copies relevant data
NOT READY AC-PAT-085 [CO] All cranial measurement fields listed in the Helmet-Specific Visit Fields table (`06_PATIENT_ASSESSMENT_HELMET.md` §Helmet-Specific Visit Fields) are present and functional, including pre-fill from scan report extraction
NOT READY AC-PAT-469 [CO] Deformation Type is captured at Initial Evaluation as a single-select between Positional and Synostotic
NOT READY AC-PAT-470 [CO] Subtype is captured as a single-select within the chosen Deformation Type. The form label shifts to "Positional Deformation Subtype" or "Synostosis Type" based on the Deformation Type selection. Full enum (5 positional subtypes, 6 synostotic subtypes) defined in `06_PATIENT_ASSESSMENT_HELMET.md` §Pathology Classification
NOT READY AC-PAT-471 [CO] The system suggests a Deformation Type based on scan measurements — primarily CVAI pattern and cephalic index. The suggestion appears to the CPO who reviews and can change it. The suggestion is never auto-applied. If scan inputs are missing or flagged low-confidence, no suggestion is shown
NOT READY AC-PAT-131 [CO] Clinical flag checkboxes are available during helmet visits (Consultation, Initial Evaluation, and Progress Review). Multiple flags can be selected
PARTIAL BE ✓ FE AC-PAT-132 [CO] Selected clinical flags are visible to the technician alongside the device configuration — the technician does not need to search the patient record
NOT READY AC-PAT-133 [CO] When atopic dermatitis is flagged, the configurator requires a Protective Layer in the Padding Layer configuration (CPO selects either Microfibre Fabric or 3D Breathable Fabric at clinical discretion)
NOT READY BE AC-PAT-113 [CO] Guardian-reported outcomes replace clinician-rated device outcomes for the infant
NOT READY AC-PAT-472 [CPO] The scan report produced by the scanner software can be uploaded to the patient record as a Document attachment. For Consultation patients (no prescription yet), this is the evidence the parents take to the prescriber
Step 4 — Helmet order, fabrication, and initial fitting (Device Delivery)
PARTIAL BE ✓ FE BE AC-PAT-357 [CPO] Device Delivery does NOT close the order — this is the start of treatment, not the end
PARTIAL BE ✓ FE BE AC-PAT-120 [BOTH] Annex XIII Section 1 statement generated at device delivery — frozen after generation
PARTIAL BE ✓ FE BE AC-PAT-121 [BOTH] Post-delivery adjustments are part of Annex XIII Section 2 documentation (living document), NOT the Section 1 statement
Step 5 — Monthly Progress Review (checkup 1)
NOT READY AC-PAT-080 [CPO] Progress Review can be created linked to the existing helmet order in IN_TREATMENT status (BR-HLM-007)
NOT READY AC-PAT-081 [CO] Baseline (Initial Evaluation) automatically linked for comparison
NOT READY BE AC-PAT-086 [CO] Cranial measurements captured and comparable to baseline for tracking progress
READY BE ✓ FE ✓ AC-PAT-065 [CO] Visit outcome required before finalisation: Continue treatment / Treatment complete / Refer out / Device replacement
NOT READY AC-PAT-051 [CO] Multiple structured device adjustments recordable per visit (using IN-PAT-008 fields)
NOT READY AC-PAT-052 [CPO] Adjustment records immutable after creation — append-only
NOT READY BE AC-PAT-087 [CO] Treatment timeline indicates which visits have scan data attached
Step 6 — Progress Reviews 2 through N
NOT READY FE AC-PAT-358 [CPO] Progress Reviews numbered sequentially per order (1, 2, 3...)
NOT READY AC-PAT-082 [CO] Treatment timeline shows all visits chronologically: date, type, scan indicator, adjustment count, visit outcome, and key measurements inline for cross-visit comparison (CVAI, Cephalic Index, cranial circumference for cranial devices)
Step 7 — Treatment complete
NOT READY BE AC-PAT-083 [CPO] Only one Progress Review per order can be marked "treatment complete"
NOT READY FE AC-PAT-359 [CPO] Treatment completion signals the Orders module to close the order. If the completion check passes, the order moves to COMPLETE and the CPO sees confirmation. If the completion check fails, the CPO sees the failure results with actionable items — they do not need to navigate to the Orders area separately to retry the transition
PARTIAL BE ✓ FE BE AC-PAT-122 [BOTH] The completion check at order completion verifies: Section 1 was already generated at delivery, Section 2 documentation is complete (all Progress Reviews, adjustments, treatment completion)
Edge Cases
NOT READY BE AC-PAT-084 [CPO] Treatment completion is final for v1. Reversal with approval is a future capability
NOT READY FE AC-PAT-360 [CPO] Attempting treatment complete on a second Progress Review for the same order is blocked
NOT READY AC-PAT-127 [CO] "Device replacement" outcome: CPO captures a new scan at this Progress Review visit. A new order is created for the replacement device, joining the same treatment sequence (flat grouping — see GLOSSARY.md: Treatment Sequence). The scan and design files belong to the triggering Progress Review and are linked to the replacement order. No separate Initial Evaluation visit is required — the triggering Progress Review serves as the clinical basis for the replacement. Because the replacement device is designed for the patient's current anatomy, the system requires device-type-specific IE-level clinical fields on the triggering Progress Review before it can be finalised (see BR-HLM-009 for cranial, BR-SPN-009 for spinal)
NOT READY AC-PAT-128 [CO] The original order stays in IN_TREATMENT while the replacement is being fabricated — the patient continues wearing the old device. Progress Reviews during this period are created on the original order. The original closes (COMPLETE with `completionReason: DEVICE_REPLACED`) when the replacement is fitted. `DEVICE_REPLACED` does not trigger treatment completion notifications and does not release the prescription
NOT READY AC-PAT-129 [CO] The replacement requires its own Clinical Prescription and Reimbursement Prescription — it is a separate custom-made device under MDR. The prescription follows the standard upload-and-parse flow. The AWAITING_PRESCRIPTION path can be used
NOT READY AC-PAT-130 [CO] The treatment timeline spans the full treatment sequence — all visits from all orders, in chronological order, with key measurements displayed inline for cross-visit comparison. Each visit is tagged with which order (device) it belongs to. The treatment baseline is the original order's Initial Evaluation. The timeline is accessible from any order in the sequence and from the patient record
NOT READY AC-PAT-473 [CO] When a device is replaced mid-treatment, the treatment timeline surfaces two reference anchors: (a) the treatment baseline — the original order's Initial Evaluation — and (b) the device reference point — the Progress Review that triggered the replacement, which serves as the starting measurement for the new device. Both anchors are displayed together so the CPO can compare current values against treatment-wide and device-specific starting points (e.g., "treatment started at CVAI 12.0" vs "this device started at CVAI 7.8")
NOT READY BE AC-PAT-115 [CPO] Guardian change during treatment: new guardian added, previous preserved in history
NOT READY FE AC-PAT-361 [CO] Visit saved as Draft if infant is uncooperative — CPO completes later
NOT READY FE AC-PAT-362 [CO] No maximum limit on number of Progress Reviews or treatment duration
#3 Prosthetic Test Socket Iterations — Returning Patient 3/33 9%
Step 1 — Open returning patient and start Initial Evaluation
PARTIAL BE FE ✓ AC-PAT-045 [CO] Medical history pre-populated from patient record, editable
NOT READY FE AC-PAT-345 [CO] Previous measurements visible alongside new measurements
PARTIAL BE FE ✓ AC-PAT-095 [CO] Previous prosthesis configurations visible with full bill of materials
NOT READY AC-PAT-053 [CO] Visit form adapts for prosthetic device type
PARTIAL BE FE ✓ AC-PAT-090 [CO] All prosthetic-specific fields present and functional
Step 2 — Complete Initial Evaluation and create order
NOT READY FE AC-PAT-363 [CO] Prosthetic Initial Evaluation minimum fields include side and K-level in addition to standard minimums (amputation level is the picker's Subcategory and is not re-asked in the IE)
Step 3 — Test Socket 1: Creation and Trial Fitting
PARTIAL BE FE ✓ AC-PAT-091 [CPO] Test socket iteration auto-numbered: "Test Socket 1"
NOT READY AC-PAT-063 [CO] Trial Fitting visit created linked to the order for Test Socket 1
READY BE ✓ FE ✓ AC-PAT-349 [CO] Clinical Prescription inherited from the order — not re-verified at each fitting
READY BE ✓ FE ✓ AC-PAT-350 [CO] Iteration outcome field present with prosthetic-specific labels: Proceed to definitive fabrication / Rebuild socket / Adjust and retest / Discontinue (device approach not viable — requires clinical justification, cancels the order)
NOT READY FE AC-PAT-364 [CO] CO documents socket fit findings: pressure distribution, alignment, suspension adequacy, gait observation, patient-reported comfort
NOT READY AC-PAT-051 [CO] Structured adjustment records for socket modifications made during fitting (using IN-PAT-008 fields)
NOT READY AC-PAT-055 [CO] Clinician-rated device outcomes captured at Trial Fitting
Step 4 — CPO selects "Rebuild socket" — iteration loop
NOT READY FE AC-PAT-365 [CPO] New test socket fabrication cycle begins within the same order — iteration increments to "Test Socket 2"
NOT READY FE AC-PAT-366 [CO] CO documents the clinical reasoning for the rebuild decision — what was wrong with the previous socket and what needs to change
PARTIAL BE FE ✓ AC-PAT-094 [CO] Full iteration history visible: all previous fittings with outcomes, adjustments, and clinical reasoning at each
Step 5 — Test Socket 2: Trial Fitting — CPO selects "Proceed to definitive"
NOT READY AC-PAT-063 [CO] Trial Fitting visit created for Test Socket 2
READY BE ✓ FE ✓ AC-PAT-350 [CO] Iteration outcome: CO selects "Proceed to definitive fabrication"
PARTIAL BE FE ✓ AC-PAT-092 [CPO] "Proceed to definitive" can only be set once per order
PARTIAL BE FE ✓ AC-PAT-094 [CO] Full iteration history visible: 2 fittings, outcomes at each, what changed between iterations
NOT READY FE AC-PAT-364 [CO] Socket fit findings documented across four evaluation stages. Each test socket iteration is represented by a Trial Fitting record with Visit A (fit-and-dispense — in-clinic seated, standing, brief dynamic, pre-dispatch post-removal inspection) and Visit B (review-after-trial — patient-reported wear experience, in-clinic examination while wearing, extended ambulation, cumulative post-removal skin inspection). The four stages at Visit A and Visit B examine different clinical content despite the shared naming. Findings include pressure distribution, alignment, suspension, gait observation, hyperemia assessment, and cumulative skin integrity trend. The definitive socket is fabricated based on the accepted test socket. See Patients Task 07 for the full Visit A / Visit B model.
Step 6 — Definitive prosthesis delivery
NOT READY AC-PAT-064 [CPO] Device Delivery with delivery confirmation and clinician-rated device outcomes
NOT READY FE AC-PAT-351 [CO] CO performs delivery examination: fit verification, alignment check, skin check, functional test, patient/caregiver education
PARTIAL BE ✓ FE BE AC-PAT-120 [BOTH] Annex XIII Section 1 statement generated at fitting/delivery — frozen after generation
Step 7 — Same patient returns 5 years later
NOT READY AC-PAT-005 [CPO] Patient can be reactivated — prompts verification of demographics and consent status
PARTIAL BE FE ✓ AC-PAT-095 [CO] Previous prosthesis orders visible with full component detail
PARTIAL BE FE ✓ AC-PAT-045 [CO] Medical history pre-populated but editable (weight, medications change over years)
NOT READY FE AC-PAT-345 [CO] Previous measurements visible alongside new measurements
Edge Cases
PARTIAL BE FE ✓ AC-PAT-049 [CO] K0 patient: CPO can mark visit fields as "clinically unavailable" with justification and proceed
PARTIAL BE FE ✓ AC-PAT-049 [CO] Open wound: measurements marked "clinically unavailable" with justification
NOT READY FE AC-PAT-367 [CPO] Attempting "Proceed to definitive" after it was already set is blocked
NOT READY AC-PAT-093 [CPO] "Proceed to definitive" is final for v1. Reversal with approval and documented clinical justification is a future capability
NOT READY BE AC-PAT-368 [CO] No hard limit on test socket iterations
#4 Consultation-Only Patient — GDPR Deletion 2/13 15%
Steps
READY BE ✓ FE ✓ AC-PAT-001 [CPO] Front Desk or CPO creates patient with minimum fields
READY BE ✓ FE ✓ AC-PAT-020 [CPO] Patient information recorded
PARTIAL BE FE ✓ AC-PAT-060 [CO] Consultation created without a Clinical Prescription and without a draft order. Minimum completion: at least one of medical history entry, physical exam finding, measurement, or clinical reasoning note
NOT READY AC-PAT-369 [CO] Proceeding to device configuration is NOT available from a Consultation — if the CPO decides a device is needed, they transition to an Initial Evaluation (consultation data carries forward per AC-PAT-062)
NOT READY AC-PAT-370 [CPO] Patient transitions to Inactive after configured inactivity period (default: 12 months)
NOT READY AC-PAT-007 [CPO] Consultation-only patient (no Clinical Prescription, no order — including no draft order) can be fully deleted
NOT READY AC-PAT-371 [CPO] Only Org Admin can delete. Requires explicit confirmation — the confirmation dialog requires typing the patient's name and lists what will be deleted (patient record, N visits, N attachments, consent records)
NOT READY AC-PAT-372 [CPO] After deletion: patient, visits, attachments, consent, patient information records all removed (cascade hard delete)
NOT READY AC-PAT-373 [CPO] Patient with a Clinical Prescription but no order (including no draft order) can be fully deleted — the prescription document is also deleted. No device was placed on the market, so no MDR retention obligation applies
NOT READY AC-PAT-374 [CPO] Patient with only draft orders (never submitted) can be deleted after draft orders are cancelled. Patient with only cancelled orders (device never fabricated) can be deleted. In both cases, no device was placed on the market
NOT READY AC-PAT-008 [CPO] Patient WITH completed or delivered device orders cannot be deleted — system explains why, lists the orders, and offers identity removal instead (see Task 02: Identity Removal)
Edge Cases
NOT READY AC-PAT-062 [CO] Consultation data carry-forward: patient returns with Clinical Prescription (izvid) → CPO starts an Initial Evaluation, consultation data pre-populates the visit. Attachments not copied. All pre-populated data editable. Most recent Consultation used if multiple exist
NOT READY AC-PAT-375 [CPO] Patient who had a Clinical Prescription entered but no order — verified as deletable per AC-PAT-373 (no MDR retention obligation without a device placed on the market)
#5 Service Visit — Routine Repair 0/4 0%
Steps
NOT READY AC-PAT-066 [CO] Service visit can be created linked to an existing order. No prescription required
NOT READY AC-PAT-376 [CO] Minimum completion: description of issue, description of work performed
NOT READY AC-PAT-051 [CO] Each device modification recorded as a distinct structured adjustment entry (using IN-PAT-008 fields)
NOT READY AC-PAT-054 [CO] CPO indicates next steps after the visit
#6 Mixed Visit — Service + Adjustment in One Appointment 0/4 0%
Steps
NOT READY AC-PAT-067 [CO] When a visit involves both service-level work (padding, strap) and prescription-level work (component replacement), the visit is recorded under the more restrictive type (Adjustment)
NOT READY AC-PAT-377 [CO] Each adjustment record includes a classification: service-level vs prescription-driven — so the distinction is captured for billing and audit, not lost in the CPO's head
NOT READY AC-PAT-378 [CO] If a CPO starts a Service visit and then realizes a prescription-driven modification is needed, the visit type can be changed to Adjustment without creating a new record
NOT READY AC-PAT-051 [CO] Each modification recorded as a distinct structured entry
#7 Role-Based Data Visibility 0/7 0%
PARTIAL BE FE ✓ AC-PAT-009 [BOTH] Each role sees only the data listed above
PARTIAL BE FE ✓ AC-PAT-010 [BOTH] Technician accesses patient data only through order context — never the patient record directly
NOT READY AC-PAT-012 [CPO] Organisation A's patients invisible to Organisation B
PARTIAL BE FE ✓ AC-PAT-011 [CPO] All patient data access logged with who, what, when
NOT READY AC-PAT-379 [BOTH] User with multiple roles: permissions are the union — most permissive access applies
NOT READY AC-PAT-381 [CPO] When a CPO switches unit context *(AC-ORG-073)*, the patient list filters to patients associated with the selected unit. Search finds patients across all of the user's assigned units — not the entire organisation. A CPO assigned only to one unit cannot search or access patients from other units
NOT READY AC-PAT-382 [CPO] Org Admin and Billing Admin can access patients across all units regardless of unit assignment — organisation-wide visibility for administrative functions. This access is still audit-trailed
#8 Returning Patient — New Device (Same Type) 0/6 0%
PARTIAL BE FE ✓ AC-PAT-045 [CO] Medical history pre-populated from patient record, editable (weight, medications change over time)
NOT READY FE AC-PAT-345 [CO] Previous measurements visible alongside new measurements for comparison
NOT READY AC-PAT-383 [CO] Previous device orders visible with full history — device type, configuration, outcomes, service history
NOT READY AC-PAT-384 [CO] Visit data from the previous order's Initial Evaluation is available for reference (not pre-populated — the CPO takes fresh measurements for a new device)
NOT READY AC-PAT-053 [CO] Visit form uses the same device-type template as the previous order (CPO can change if the device type has changed)
NOT READY AC-PAT-005 [CPO] If the patient was Inactive, reactivation prompts verification of demographics and consent status
#9 Returning Patient — Different Device Type 0/4 0%
NOT READY AC-PAT-053 [CO] Visit form adapts to the NEW device type — different template from the previous order
PARTIAL BE FE ✓ AC-PAT-045 [CO] Medical history carries forward (patient-level, device-type-independent)
NOT READY AC-PAT-385 [CO] Previous measurements from a different device type are visible for reference but may not be anatomically relevant — the CPO decides what's useful
NOT READY AC-PAT-383 [CO] Full device history visible regardless of device type — the CPO can see all previous orders
#10 Warranty Claim 0/4 0%
NOT READY AC-PAT-068 [CO] Warranty Assessment can be created linked to the order. No prescription required
NOT READY AC-PAT-386 [CO] Minimum completion: description of issue, warranty determination (covered / not covered / referred to manufacturer)
NOT READY AC-PAT-051 [CO] Any device modifications recorded as structured adjustment entries
NOT READY AC-PAT-387 [CPO] Warranty determination is documented for audit — who determined, when, reasoning
#11 Adjustment with New Clinical Prescription 0/4 0%
NOT READY AC-PAT-067 [CO] Adjustment visit created linked to the order. Requires a new Clinical Prescription (izvid) from the physician authorizing the modification
NOT READY AC-PAT-030 [CPO] New Clinical Prescription entered with all required fields (prescriber, diagnosis, device modification authorised, laterality, ICD code, dates)
NOT READY AC-PAT-051 [CO] Structured adjustment records capture what was changed, why, and classify each modification as prescription-driven
NOT READY AC-PAT-054 [CO] CPO indicates next steps — schedule follow-up, mark as complete, etc.
#12 Patient Transfer Between COs 0/3 0%
NOT READY AC-PAT-388 [CO] The incoming CPO can see the complete treatment history — all visits, all adjustments, all clinical reasoning by the previous CPO
NOT READY AC-PAT-389 [CO] No data is lost or hidden when a different CPO opens the patient record — the record is the same regardless of which CPO views it
PARTIAL BE FE ✓ AC-PAT-011 [CPO] All access is logged — the incoming CPO's access to the patient record is audit-trailed
#13 Multi-Device Patient 0/4 0%
NOT READY AC-PAT-390 [CO] All active orders for the patient are visible from the patient record — clearly distinguishable by device type, order number, and status
NOT READY AC-PAT-391 [CO] The CPO can navigate between orders without leaving the patient context
NOT READY AC-PAT-392 [CO] Visit data is order-specific — measurements for the AFO order are separate from measurements for the prosthetic order
PARTIAL BE FE ✓ AC-PAT-045 [CO] Medical history is shared (patient-level) — the CPO doesn't re-enter it per order
#14 Patient Discharge (Clinician-Initiated Inactivity) 0/4 0%
NOT READY AC-PAT-393 [CPO] Clinician discharge requires no open orders — blocked with message if open orders exist
NOT READY AC-PAT-394 [CO] Only CPO or Org Admin can initiate clinician discharge
NOT READY AC-PAT-395 [CPO] Inactive patients (including discharged) remain searchable and viewable (read-only) — they are not deleted
NOT READY AC-PAT-005 [CPO] An inactive patient (including discharged) can be reactivated if they return
#15 Patient-to-Order Seamless Flow (Cross-Module) 0/6 0%
NOT READY AC-PAT-200 [BOTH] When the CPO proceeds from a visit to device configuration, patient data (measurements, contraindications, prescriber details, linked scans/images) is already populated — no re-entry. The order is created silently
NOT READY AC-PAT-201 [BOTH] The CPO can navigate back to the patient record from the order context and return to the order without losing work
NOT READY AC-PAT-202 [BOTH] Device type selection reflects the visit context — if the CPO assessed for an AFO, the device type is pre-suggested (but changeable)
NOT READY AC-PAT-203 [BOTH] When the CPO proceeds to device configuration, the configurator applies the pre-fills defined for the device type (per its component tree spec). The CPO reviews and adjusts; pre-fill scope varies by device type — some device types pre-fill from clinical assessment, others only from fabrication-method choices
NOT READY AC-PAT-204 [BOTH] The CPO can complete the full flow (patient creation → visit → device selection → component configuration → offer → order confirmation) without leaving the workflow or re-entering data at any step
PARTIAL BE ✓ FE AC-PAT-205 [BOTH] Clinical Prescription verification and Reimbursement Prescription validation happen at the appropriate moments (per AC-PAT-327 and AC-PAT-323) without interrupting the flow — the system guides, not blocks
#16 Scoliosis Brace — Treatment Monitoring 0/23 0%
Step 1 — Initial Evaluation
NOT READY AC-PAT-431 [CO] Scoliosis Initial Evaluation captures all required fields: scoliosis etiology, Rigo classification (variants A1, A2, A3, B1, B2, C1, C2, E1, E2 + D modifier if structural proximal thoracic curve is present), Cobb angle (out-of-brace), Risser sign, curve location (cervical, cervicothoracic, thoracic, thoracolumbar, lumbar), curve direction (left/right convexity), curve count (single/double/triple), leg length discrepancy, and shoulder asymmetry
NOT READY AC-PAT-432 [CO] Sagittal plane fields (thoracic kyphosis angle, lumbar lordosis angle) are available for scoliosis visits — scoliosis is a three-dimensional deformity and the Cheneau brace requires sagittal profile data
NOT READY AC-PAT-433 [CO] Trunk shift (coronal balance) and trunk rotation (scoliometer) are available as clinical examination fields
NOT READY AC-PAT-434 [CO] Flexibility (side-bending Cobb angle) and flexibility measurement method (supine, standing, fulcrum, traction) are available
NOT READY AC-PAT-435 [CO] Menarche status (pre-menarchal, post-menarchal, months since menarche) is available for female patients
NOT READY AC-PAT-436 [CO] Trunk measurements for fabrication are captured: chest circumference, waist circumference, hip circumference, trunk length (axilla to iliac crest), shoulder width, and impression method (scan/cast)
NOT READY AC-PAT-437 [CO] In-brace/out-of-brace defaults to out-of-brace at Initial Evaluation — the patient does not have a brace yet
Step 2 — Proceed to device configuration
NOT READY AC-PAT-438 [CO] Rigo classification from the visit pre-fills the Cheneau configurator's conditional rules (pad placement, expansion chambers, extensions)
Step 3 — Progress Review (6 months later)
NOT READY AC-PAT-439 [CO] Curve classification fields (etiology, Rigo, location, direction, count) are carried forward from Initial Evaluation — the CPO reviews and can update if presentation changed
NOT READY AC-PAT-440 [CO] Both in-brace and out-of-brace Cobb angles are captured at Progress Review. The system automatically calculates in-brace correction percentage and displays it with a visual indicator (≥50% on target, below 50% below target)
NOT READY AC-PAT-441 [CO] Brace wear compliance (target vs actual hours) is captured
Step 4 — Treatment completion (weaning protocol)
NOT READY AC-PAT-442 [CO] When the patient approaches skeletal maturity (Risser 4–5), the CPO begins a weaning protocol — reducing prescribed wear hours gradually (e.g., 23h → 16h → nighttime only → discontinuation) while monitoring for curve progression at each Progress Review
NOT READY AC-PAT-443 [CO] The CPO uses "continue treatment" visit outcome throughout the weaning phase, recording the reduced wear schedule in the compliance field. Treatment is marked complete only when weaning is finished and the curve remains stable
Step 5 — Edge case: combined scoliosis-kyphosis
NOT READY AC-PAT-444 [CO] When both scoliosis and kyphosis are present, both field sets are captured on the same visit. Progress Reviews track both Cobb angles (coronal and sagittal) and both correction percentages
Edge Cases
NOT READY AC-PAT-445 [CO] Kyphosis Initial Evaluation captures all required fields: kyphosis angle (out-of-brace), Risser sign, location (thoracic/thoracolumbar), and flexibility (prone extension — reducible vs structural)
NOT READY AC-PAT-446 [CO] When Scheuermann's kyphosis is suspected, diagnostic criteria are captured as structured fields: anterior vertebral wedging ≥5° at 3+ consecutive vertebrae (yes/no), Schmorl's nodes (present/absent), endplate irregularity (present/absent). The lateral radiograph is uploaded as an attachment
NOT READY AC-PAT-447 [CO] Spinal-specific fields (Rigo classification, Cobb angle, curve location, etc.) are hidden when assessing for a non-spinal device
NOT READY AC-PAT-459 [CO] Leg length discrepancy (cm and side) is captured at scoliosis Initial Evaluation — uncorrected LLD causes pelvic obliquity that mimics or exaggerates scoliosis
NOT READY AC-PAT-460 [CO] Shoulder asymmetry (cm and elevated side) is captured at scoliosis Initial Evaluation and re-evaluated at Progress Reviews in-brace
NOT READY AC-PAT-461 [CO] Trunk rotation (Adams forward bend test) captures both the scoliometer reading in degrees and the CPO's interpretation of which rotational prominences are structural vs compensatory
NOT READY AC-PAT-462 [CO] Height velocity (cm per year) is auto-calculated from visit height data when at least two visits are available — surfaced alongside Risser sign to contextualise growth spurt timing
NOT READY AC-PAT-463 [CO] Body habitus assessment is available for scoliosis visits — affects pad depth calculations and skin breakdown risk
NOT READY AC-PAT-464 [CO] Thoracic kyphosis angle surfaces a clinical warning if the value indicates thoracic lordosis (reversal of normal kyphosis) — orthotic treatment is contraindicated for true thoracic lordosis
#17 Lower Limb Orthotic Visit 0/15 0%
Step 1 — Initial Evaluation with pathology classification
NOT READY AC-PAT-448 [CO] The 12 orthotic SubCategory values (DROP_FOOT, SPASTIC_EQUINUS, SPASTIC_EQUINOVARUS, CROUCH_GAIT, KNEE_RECURVATUM, KNEE_INSTABILITY, KNEE_VALGUS_VARUS, HIP_INSTABILITY, ANKLE_INSTABILITY, FOOT_DEFORMITY, IMMOBILISATION, GAIT_DEVIATION_COMPLEX) are available when the device type is a lower limb orthotic
NOT READY AC-PAT-449 [CO] Type values are filtered to the selected SubCategory — e.g., selecting DROP_FOOT shows only COMPLETE_PARALYSIS, PARTIAL_WEAKNESS, PROGRESSIVE, RECOVERING
NOT READY AC-PAT-450 [CO] The selected SubCategory and Type populate the order's `pathologySubCategory` and `pathologyType` respectively
NOT READY AC-PAT-451 [CO] Functional Grade (FG-1 through FG-4) is used for orthotic patients. K-level field is hidden
Step 2 — Functional assessment fields
NOT READY AC-PAT-452 [CO] Lower limb orthotic Initial Evaluation captures all required fields: Functional Grade, primary functional presentation, clinical specification, range of motion per relevant joint, deformity flexibility (when deformity is present), muscle strength (MMT), weight-bearing status, skin condition, and footwear (AFO/KAFO/HKAFO)
NOT READY AC-PAT-453 [CO] When the SubCategory is neurological (DROP_FOOT, SPASTIC_EQUINUS, SPASTIC_EQUINOVARUS, CROUCH_GAIT, KNEE_RECURVATUM, GAIT_DEVIATION_COMPLEX), muscle tone assessment (Modified Ashworth Scale) is required in addition to muscle strength
NOT READY AC-PAT-454 [CO] Gait observation with structured prompts per deviation type is captured
Step 3 — Fabrication measurements
NOT READY AC-PAT-455 [CO] Fabrication measurements are captured at Initial Evaluation: circumference measurements at multiple levels per device type, length measurements, joint axis locations, foot length and width, and impression method (scan/cast/foam box)
Step 4 — Proceed to device configuration
NOT READY AC-PAT-456 [CO] The selected pathology SubCategory and Type pre-fill the configurator's conditional rules — e.g., DROP_FOOT pre-fills a dorsiflexion assist hinge, SPASTIC_EQUINUS pre-fills a plantarflexion stop
Edge Cases
NOT READY AC-PAT-457 [CO] When a patient has multiple functional deficits (e.g., spasticity + drop foot), the CO classifies by the dominant biomechanical problem. The full clinical picture is captured in the visit narrative
NOT READY AC-PAT-458 [CO] Orthotic-specific fields (Functional Grade, gait observation, muscle tone, pathology SubCategory/Type) are hidden when assessing for a non-orthotic device
NOT READY AC-PAT-465 [CO] When DIABETIC_NEUROPATHY is selected and sensation is absent or reduced, the system surfaces a safety warning if the CPO selects a corrective device type — corrective forces on insensate feet can cause pressure ulceration
NOT READY AC-PAT-466 [CO] Sensation assessment uses Semmes-Weinstein monofilament grading (4.17/5.07/6.10) for diabetic/neuropathic patients. Loss of protective sensation (5.07 or worse) triggers accommodative-only design
NOT READY AC-PAT-467 [CO] Footwear is required for AFO, KAFO, and HKAFO assessments — the AFO-footwear combination is a biomechanical unit
NOT READY AC-PAT-468 [CO] Deformity flexibility (flexible/fixed/mixed) is captured per affected joint when deformity is present — determines whether the device corrects or accommodates
⚙ Cross-Cutting Concerns 1/62 2%
Patient Lifecycle
NOT READY AC-PAT-396 [CPO] Patient starts as Active at record creation — no separate New state
NOT READY AC-PAT-006 [CPO] Active → Inactive: blocked if open orders exist, with message listing affected orders. Each transition carries a reason (automatic inactivity, clinician discharge, other)
NOT READY AC-PAT-005 [CPO] Inactive → Active: prompts demographics and consent verification
NOT READY AC-PAT-397 [CPO] Archived is terminal — no transition out. If an archived patient returns, a new record is created with a reference to the archived one
NOT READY AC-PAT-398 [CPO] Invalid transitions rejected (e.g., Active → Archived directly — must go through Inactive first)
Clinical Prescription Lifecycle
NOT READY AC-PAT-032 [CPO] Clinical Prescriptions are immutable after creation — corrections supersede the original, which is preserved in the audit trail
NOT READY AC-PAT-399 [CPO] When a Clinical Prescription expires or is superseded, existing orders linked to it remain valid
NOT READY AC-PAT-400 [CPO] Clinical Prescription records linked to device orders retained for minimum 10 years
Reimbursement Prescription Lifecycle
NOT READY AC-PAT-401 [CPO] A Reimbursement Prescription (naročilnica) must reference a valid Clinical Prescription — it cannot exist independently
NOT READY AC-PAT-402 [CPO] Reimbursement Prescription approval status is tracked: Pending, Approved, Denied, Partially Approved
NOT READY AC-PAT-403 [CPO] For insured patients (Paths A, B, C), the device cannot be fitted to the patient until the Reimbursement Prescription is approved (BR-RX-009). When the CPO attests clinical urgency (BR-ORD-022a), fabrication may begin before approval — but FITTING is blocked until the Reimbursement Prescription is linked
NOT READY AC-PAT-404 [CPO] When an order is cancelled, the Reimbursement Prescription is voided and must be reissued for any new order
Consent Lifecycle
PARTIAL BE ✓ FE AC-PAT-023 [CPO] Consent withdrawal recorded with timestamp; previous status preserved
NOT READY AC-PAT-405 [CPO] Withdrawal stops future non-clinical processing; MDR-obligated data retained
NOT READY AC-PAT-406 [CO] Clinical processing continues unaffected by consent withdrawal — never consent-based
NOT READY AC-PAT-407 [CPO] If a guardian withdraws non-clinical consent while a paediatric patient has an active order (including IN_TREATMENT), clinical processing (visits, Progress Reviews, device adjustments) continues under the treatment lawful basis. The withdrawal affects only non-clinical processing (marketing, research data sharing). The system does not prompt the CPO to stop treatment
NOT READY AC-PAT-408 [CPO] Attachments on released orders remain accessible regardless of non-clinical consent withdrawal
Visit Lifecycle
NOT READY AC-PAT-042 [CO] Draft → Complete is an explicit action by the CPO — not triggered by saving or navigating away. Saving preserves Draft status
NOT READY FE AC-PAT-361 [CPO] When the CPO chooses to finalise, the system checks minimum required fields (BR-PAT-020). Missing fields are listed with two actions: 'Go to field' and 'Mark as clinically unavailable' (BR-PAT-027)
NOT READY AC-PAT-409 [CPO] The CPO sees a confirmation before the visit transitions to Complete
PARTIAL BE FE ✓ AC-PAT-043 [CPO] On completion: CPO identity and completion timestamp recorded
NOT READY AC-PAT-044 [CPO] Completed visits can be amended (new version created, original version preserved with its completion record). The amendment records who amended, when, and what changed
NOT READY AC-PAT-410 [CPO] When a completed visit is amended and that visit is linked to an existing order, the order is flagged with a notice: "Source visit updated." The CPO who created the order is notified. If the order is in DRAFT, the CPO can edit the IE entry on the order directly to reflect the amendment. If the order has left DRAFT (AWAITING_PRESCRIPTION onwards), the IE entry is locked — the order must be cancelled and a new one started if the clinical data is materially different
NOT READY AC-PAT-411 [CPO] Visit completion is idempotent — if already Complete, a second completion attempt is a no-op
NOT READY AC-PAT-412 [CPO] Draft visits can be cancelled (voided) by the CPO — soft-deleted, preserved in audit trail, hidden from working view. Completed visits cannot be cancelled
NOT READY AC-PAT-413 [CPO] Draft visits are auto-saved periodically. If a save fails, the CPO sees an error with the option to retry
NOT READY AC-PAT-475 [CPO] In the new-medical-device wizard, the Initial Evaluation remains in Draft for the entire wizard flow (Steps 3, 4, 5). While the linked order is in DRAFT, the IE's clinical fields remain editable — the CPO can return to Step 3 and revise them freely. The IE transitions to Complete atomically with the order leaving DRAFT at the "Confirm device configuration" commit (Step 5). No separate "finalise IE" action exists in the wizard
Attachments
READY BE ✓ FE ✓ AC-PAT-100 [CPO] Attachments belong to the device order they were uploaded against, organised in five sections (Consents and Receipts, Medical Device Documents, Clinical Evidence Reports, Scan Files, Photos and Videos). The visit during which a file was uploaded is recorded against the file for audit purposes, but the visit does not own the file
NOT READY BE AC-PAT-106 [CPO] Attachments cannot be hard-deleted — only soft-deleted/archived
NOT READY BE AC-PAT-107 [CPO] Attachments on orders that produced a placed-on-market device retained for minimum 10 years (MDR Art 10(8)). Consultation-only attachments deleted with the patient record
NOT READY BE AC-PAT-108 [CPO] Technicians access an order's attachments only by opening the order — no direct browsing of the patient record
NOT READY AC-PAT-117 [CPO] Soft-deleted attachments remain accessible through existing order links (MDR retention) but are hidden from the patient's file history
NOT READY AC-PAT-208 [BOTH] Attachments inherit the patient and device context from the order they are uploaded against — no additional metadata entry required from the CPO at upload time
NOT READY AC-PAT-209 [BOTH] A patient's attachments are reachable through the patient's orders — opening any order shows that order's files. The patient timeline indexes which order each file belongs to and which visit it was uploaded during
NOT READY AC-PAT-210 [BOTH] Quick Observation can be created with minimum fields: date, linked device/order, one free-text note. No prescription required. Can repeat. Can trigger service or repair orders
Notifications
NOT READY AC-PAT-414 [CPO] Any notifications triggered by Patients-area events (prescription approaching expiry, visit completion, consent changes, transparency reminders) contain order reference numbers only — no patient name, contact details, or clinical data in the notification content. The user navigates to the platform to see full detail
Patient Data Editing
NOT READY AC-PAT-014 [CPO] Front Desk can edit patient demographics (name, contact, address, insurance) at any time while the patient is Active
NOT READY AC-PAT-415 [CO] CPO can edit clinical data (medical history, contraindications, allergies) at any time — these are patient-level and evolve over time
NOT READY AC-PAT-416 [CPO] All edits to patient data are tracked with who changed what and when (audit trail)
NOT READY AC-PAT-417 [CPO] Editing is blocked for Archived patients — the record is read-only
NOT READY AC-PAT-418 [CPO] Editing Inactive patients triggers a reactivation prompt before changes can be saved
NOT READY AC-PAT-032 [CPO] Clinical Prescriptions are immutable after creation — corrections supersede the original, which is preserved in the audit trail
NOT READY AC-PAT-052 [CPO] Adjustment records are immutable — append-only, soft delete for errors
NOT READY AC-PAT-044 [CPO] Completed visits can be amended via new version (see Visit Lifecycle section)
Contextual Field Visibility
NOT READY AC-PAT-015 [CPO] Guardian fields (name, relationship, phone, email, primary contact) are collapsed by default for adult patients but expandable on demand — a CPO may need guardian or caregiver contact details for adults with cognitive disability, dementia, or elderly patients whose family manages their care
NOT READY AC-PAT-419 [CO] Guardian-reported outcomes are hidden for adult patients — only shown when the patient cannot self-report
NOT READY AC-PAT-420 [CO] Infant-specific cranial fields (fontanelle status, torticollis present) are hidden for adult protective helmet visits
NOT READY AC-PAT-421 [CO] Prosthetic-specific fields (side, K-level, residual limb, socket design, etc.) are hidden when assessing for an orthotic or cranial device
NOT READY AC-PAT-422 [CO] Cranial measurement fields (per Helmet-Specific Visit Fields table in `06_PATIENT_ASSESSMENT_HELMET.md`) are hidden when assessing for an orthotic or prosthetic device
NOT READY AC-PAT-423 [CO] K-level field is hidden for orthotic visits — Functional Grade (see GLOSSARY.md) is used instead
NOT READY AC-PAT-424 [CO] Treatment monitoring fields (Progress Review, treatment timeline, treatment completion) are hidden for devices without a treatment phase
NOT READY AC-PAT-425 [CO] Protective helmet visits do not display corrective reshaping fields (CVAI, CI, severity classification, etc.)
NOT READY AC-PAT-474 [CO] Trial Fitting visit type is not offered on cranial helmet orders — the visit creation menu hides Trial Fitting for cranial helmet device types. Helmets do not use the test device phase; iteration happens post-delivery via Progress Reviews (per `06_PATIENT_ASSESSMENT_HELMET.md`)
NOT READY AC-PAT-426 [CO] Consultation shows general visit fields only — no order-linked fields, no device configuration, no iteration outcomes
NOT READY AC-PAT-427 [CO] Service visits show a focused view: issue description, work performed, adjustment records — not the full Initial Evaluation field set
NOT READY AC-PAT-428 [CO] Follow-Up visits show a focused view: device fit, skin condition, wear pattern, outcomes — not the full Initial Evaluation field set
NOT READY AC-PAT-429 [CO] Warranty visits show: issue description, warranty determination — not full clinical visit fields
NOT READY AC-PAT-430 [CO] For unilateral devices, measurement fields for the untreated side are hidden (the CPO can expand them if needed for comparison)
Regulatory Traceability
PARTIAL BE ✓ FE BE AC-PAT-120 [BOTH] Annex XIII Section 1 statement (point-in-time) generated at fitting/delivery for all devices. Frozen after generation
PARTIAL BE ✓ FE BE AC-PAT-121 [BOTH] Post-delivery adjustments and treatment monitoring are Annex XIII Section 2 documentation (living document), not Section 1
PARTIAL BE ✓ FE BE AC-PAT-122 [BOTH] For devices with a treatment phase: Section 1 readiness checkpoint at FITTING → IN_TREATMENT. The completion check at IN_TREATMENT → COMPLETE verifies Section 1 was already generated and Section 2 is complete
NOT READY BE AC-PAT-123 [BOTH] Complete device record (Section 1 + Section 2 + adjustment history) retained for minimum 10 years from the date the device was placed on the market (which for custom-made devices = delivery to patient). Note: 15-year retention applies for implantable custom-made devices per MDR Article 10(8)

Orders & Configuration

15 ready 34 partial 130 not ready 179 total
#1 New AFO Order — End-to-End 3/50 6%
Step 1 — Select device type, complete Initial Evaluation, proceed to configuration
NOT READY AC-ORD-001 [CPO] When a CPO selects a device type (Device Category and Subcategory) for a patient, the order is created silently in DRAFT — no explicit "Create Order" action
NOT READY AC-ORD-135 [BOTH] The Orders area does not contain a "Create Order" button or any order initiation action. Orders can only be initiated from within a clinical event context (patient page, service visit, warranty evaluation). The Orders area is a monitoring dashboard showing in-progress orders and awaiting-action items
NOT READY AC-ORD-136 [BOTH] Where the patient already has clinical signal (existing prescription, diagnosis, prior order), the system suggests a device type. The CPO confirms or picks a different type. No blank dropdown requiring the CPO to pick from scratch when the platform already knows the answer
NOT READY AC-ORD-002 [CPO] The order record contains a link to the patient at creation; links to visit and prescription are added at Initial Evaluation completion
NOT READY AC-ORD-003 [BOTH] The IE entry on the order is editable while the order is in DRAFT and locked once the order leaves DRAFT (AWAITING_PRESCRIPTION onwards). Post-DRAFT corrections require cancelling the order and starting a new one
NOT READY BE AC-ORD-138 [CPO] Proceeding to configuration is blocked if the Initial Evaluation is currently being edited by another user — the CPO sees a message indicating the visit has unsaved changes. Proceeding is permitted only from a saved (Draft or Complete) visit
NOT READY AC-ORD-140 [CPO] When the source visit linked to an order has been amended (per AC-PAT-410), the order detail view displays a notice: "Source visit updated." If the order is in DRAFT, the CPO can edit the IE entry on the order to reflect the amendment. If the order has left DRAFT, the IE entry is locked and the order must be cancelled if the clinical data is materially different
NOT READY AC-ORD-007 [CPO] Only CPOs can create new device orders; Production Managers can create repair and maintenance orders
PARTIAL BE ✓ FE AC-ORD-008 [CPO] Orders are scoped to the organisation — users in Organisation A cannot see Organisation B's orders
NOT READY AC-ORD-141 [CPO] Within a multi-unit organisation, orders are assigned to the unit where they were created. When a CPO switches unit context *(AC-ORG-073)*, the order list filters to orders for the selected unit. Orders from other units are accessible via search but not shown in the default list. Org-level roles (Org Admin) see all orders across all units regardless of unit context
Step 2 — Configure device in the visual configurator
NOT READY SPEC AC-ORD-030 [BOTH] The configurator displays a visual representation of the device — not a form with dropdowns
NOT READY AC-ORD-031 [CO] Pre-filled mode loads all components per the device type's component tree
NOT READY AC-ORD-032 [CO] Every pre-filled component can be changed, removed, or swapped
NOT READY AC-ORD-033 [CO] Build-from-scratch mode starts with an empty canvas and allows manual component addition
NOT READY AC-ORD-034 [CPO] Switching between modes preserves existing component selections
READY BE ✓ BE-only AC-ORD-036 [CPO] All component actions are logged with timestamp and user
NOT READY AC-ORD-037 [CO] Device categories and types are supported per the defined table
NOT READY AC-ORD-048 [CPO] Reimbursement codes are visible on each component
Step 3 — Attachments
NOT READY AC-ORD-167 [CPO] Required attachments by device type block "Send to Production" until present — hard block
NOT READY AC-ORD-168 [CPO] Production staff see an order's fabrication-relevant attachments with patient PII stripped
NOT READY AC-ORD-169 [CPO] A CPO can remove an attachment from an order while the order is in DRAFT, AWAITING_PRESCRIPTION, or READY_FOR_PRODUCTION; once the order is in IN_PRODUCTION, removal is no longer possible
Step 4 — Set payment path (Path A)
NOT READY FE AC-ORD-080 [CPO] Four payment paths (A, B, C, D) are supported and documented on the order
PARTIAL BE ✓ FE AC-ORD-086 [CPO] Order total is calculated from component unit prices — not manually entered
PARTIAL BE ✓ FE AC-ORD-087 [CPO] Insurance budget is displayed alongside the order total for comparison
NOT READY AC-ORD-088 [CPO] Payment path is required before order submission (submission prerequisite)
Step 5 — Confirm device configuration (saves to DRAFT)
NOT READY AC-ORD-092 [BOTH] "Confirm device configuration" prerequisites verify required components, no hard-block errors, required attachments, documented overrides, prescriber details, and payment path
PARTIAL BE ✓ FE AC-ORD-017 [CPO] Every status transition is logged with timestamp, user, and notes
NOT READY AC-ORD-010 [CPO] All 11 v1 statuses are supported with the defined transitions. The deferred `PENDING_APPROVAL` status (`[post-Leipzig]`) is documented in Task 03
Step 6 — Send to Production (DRAFT or AWAITING_PRESCRIPTION → READY_FOR_PRODUCTION → IN_PRODUCTION → READY_FOR_FITTING)
PARTIAL BE FE ✓ AC-ORD-006 [CPO] The order reference number is assigned at DRAFT creation (device-type selection) and persists unchanged through every subsequent transition. Cancellation in DRAFT, AWAITING_PRESCRIPTION, or READY_FOR_PRODUCTION permanently retires the reference number
NOT READY AC-ORD-155 [BOTH] The order reference number format is defined per organisation in Organisation Settings — Pentla does not impose a single platform-wide format. The platform follows the organisation's existing numbering scheme
NOT READY AC-ORD-156 [BOTH] The order sequence is a single monotonic counter at the organisation level, shared across all units. Two orders never receive the same sequence value
NOT READY AC-ORD-157 [BOTH] Two patients whose names produce identical letter prefixes are disambiguated by the sequence number alone — no additional suffix is added to handle name collisions
NOT READY AC-ORD-158 [CPO] Established organisations onboarding to Pentla can configure a starting sequence value so the platform continues their existing numbering instead of restarting at 1
NOT READY AC-ORD-159 [CPO] Changing the reference number format in Organisation Settings affects only future orders; existing reference numbers are preserved as-is
NOT READY AC-ORD-163 [CPO] A second click on "Send to Production" for an order that has already left DRAFT is a no-op — no duplicate transition, no duplicate notification, no duplicate audit entry. Concurrent clicks from two qualified users surface "the order has already been released" inline to the second clicker
NOT READY AC-ORD-164 [CPO] When a hard requirement on a DRAFT or AWAITING_PRESCRIPTION order reverts to unmet (e.g., the Clinical Prescription expires while the order sits in DRAFT, the Reimbursement Prescription is voided, a recorded Path D payment is reversed), the "Send to Production" button re-disables and the hard-requirement checklist refreshes inline to show the missing item
NOT READY AC-ORD-165 [CPO] When a pre-fabrication order is cancelled, the Cancelled-Order Audit Record is created on the patient with all six fields populated: retired reference number, device type, created at / created by, created during visit, cancelled at / cancelled by, and structured cancellation reason
NOT READY AC-ORD-166 [CPO] An attachment upload that is in flight when an order is cancelled either completes against the order's cancellation retention tier or fails cleanly — no orphaned attachments are left referencing a cancelled order, and the cascade is never partially applied
NOT READY AC-ORD-168 [CPO] Production staff see an order's fabrication-relevant attachments with patient PII stripped
Step 7 — Fitting
PARTIAL BE FE ✓ AC-ORD-100 [BOTH] Every device passes through FITTING before COMPLETE — no shortcut exists
PARTIAL BE ✓ FE AC-ORD-101 [CO] Fitting assessment can be recorded with fit evaluation, adjustments, and clinical notes
READY BE ✓ FE ✓ AC-ORD-102 [CO] Clinician-rated device outcomes are captured at fitting per the Patients area model (AC-PAT-055): comfort, function, satisfaction, pain, cosmetic acceptability, wear time, issues reported
NOT READY AC-ORD-103 [CPO] Adjustments are append-only and cannot be deleted
READY BE ✓ FE ✓ AC-ORD-104 [CO] Base workflow: FITTING → COMPLETE after acceptance
Step 8 — Complete order
NOT READY AC-ORD-093 [BOTH] Completion prerequisites verify fitting documentation, PROs, serial numbers, traceability chain, and Annex XIII readiness before completion
NOT READY BE AC-ORD-076 [CPO] All Annex XIII required fields are present in the order data model
Edge Cases
PARTIAL BE ✓ FE DEP AC-ORD-035 [CO] Bilateral flag creates L/R pair with mirror or independent configuration per AC-CTE-022 through AC-CTE-025; each side is independently editable when in independent mode. Bilateral handling applies to orthotic devices — prosthetic bilateral patients create two separate orders (one per side) per BR-PROS-006, because each residual limb has independent test socket iterations and completion timelines
NOT READY AC-ORD-004 [CPO] Draft orders can be saved and resumed later
PARTIAL BE ✓ FE AC-ORD-005 [CPO] DRAFT, AWAITING_PRESCRIPTION, and READY_FOR_PRODUCTION orders are cancelled (hard-delete substantive content + retain a cancelled-order audit record on the patient) — there is no separate delete operation. Orders that have entered IN_PRODUCTION or later cannot be hard-deleted; cancellation retains all data per MDR Article 10(8)
PARTIAL BE FE ✓ AC-ORD-012 [CPO] `FITTING` is required before `COMPLETE` — no shortcut from `READY_FOR_FITTING` to `COMPLETE` exists
#2 Prosthetic Order with Test Socket 1/20 5%
Step 1 — Create order and configure prosthesis
NOT READY AC-ORD-046 [CO] Pre-fill logic populates components based on visit data and patient context
NOT READY AC-ORD-047 [CO] K-level pre-fill is scoped to prosthetics — not applied to all device types
PARTIAL BE FE ✓ AC-ORD-014 [CO] `TEST_DEVICE_*` statuses are only available for orders whose device type includes the test device phase
PARTIAL BE FE ✓ AC-ORD-015 [CPO] The test device phase and treatment phase are independent — a device type may include either, both, or neither
Step 2 — Submit and fabricate test socket
NOT READY AC-ORD-011 [CPO] The unified status flow applies to all orders, with optional phases determined by device type
Step 3 — Test socket Visit A (fit-and-dispense)
NOT READY AC-ORD-143 [CPO] The `FITTING` → `TEST_SOCKET_IN_USE` transition is hard-blocked without a linked Clinical Prescription; blocked attempts are logged as attempted-transition evidence (who, when, missing prescription)
NOT READY AC-ORD-144 [CPO] Visit A and Visit B outcome vocabularies are distinct. Visit A uses dispatch outcomes (dispatched supervised / unsupervised, not-dispatched rebuild / adjust-in-clinic / discontinue, patient declined, deferred); Visit B uses the universal four-way Trial Fitting enum. No same-day approval outcome exists on Visit A
PARTIAL BE ✓ FE AC-ORD-016 [CO] Test socket approve/rebuild decisions can only be made by a CPO
Step 4 — Home trial period (TEST_SOCKET_IN_USE)
NOT READY AC-ORD-145 [CPO] `TEST_SOCKET_IN_USE` is available for orders whose device type includes the test device phase. The status represents the home trial period — the test socket is in the patient's possession between Visit A dispatch and Visit B return
NOT READY AC-ORD-146 [CPO] The order exits `TEST_SOCKET_IN_USE` on a scheduled Visit B return or on an interrupted-trial early return. Both transitions return the order to `FITTING` for in-clinic evaluation
Step 5 — Test socket Visit B (review-after-trial)
NOT READY AC-ORD-106 [CO] Test device phase: each test socket iteration spans a Visit A (fit-and-dispense), a home trial period, a Visit B (review-after-trial), and optional Visit C (in-clinic adjustment) entries. Visit B allows proceed-to-definitive, rebuild, adjust-and-retest, or discontinue decisions
PARTIAL BE ✓ FE AC-ORD-108 [CO] Test socket iterations are numbered (anchored to the fabricated test socket). Each iteration is represented by one Trial Fitting record on the patient file, containing one or more visit entries
NOT READY AC-ORD-147 [CPO] For prosthetic orders in the test device phase, component swap scope is limited to knee unit and foot unit; swaps, finalisations, and un-finalisations are captured via the structured ComponentDecision model with component-class-specific reason enums
Step 6 — Rebuild iteration
NOT READY AC-ORD-148 [CPO] An in-clinic adjustment that materially changes the socket's contact surfaces closes the current iteration with a Rebuild outcome and starts a new iteration (per BR-PROS-009)
READY BE ✓ BE-only DEP AC-ORD-009 [CPO] Component modifications during `FITTING` and FITTING are logged with what changed, clinical reasoning, timestamp, and user
NOT READY DEP AC-ORD-039 [CO] The configurator can be reopened during `FITTING` and FITTING to swap components
Step 7 — Proceed to definitive device
Edge Cases
NOT READY AC-ORD-106 [CO] Unlimited test socket iterations — no system-imposed maximum
PARTIAL BE FE ✓ AC-ORD-100 [CPO] Completion serial number check applies to definitive device components only — test socket components are exempt
NOT READY AC-ORD-149 [CPO] Test sockets are treated as temporary custom-made fabrication aids, not independent custom-made devices. A test socket does not generate its own Annex XIII Section 1 statement; Trial Fitting records are retained as part of the definitive device's Annex XIII Section 2 documentation
NOT READY AC-ORD-150 [CPO] Clinical safety gates on test socket dispatch (Clinical Prescription, CPO Clinical Attribution, patient/legal representative acknowledgement, pre-dispatch safety check) apply regardless of the fabrication-aid position
#3 Treatment Phase Devices (Cranial Helmets, Scoliosis Braces) 2/12 17%
Step 1 — Create order and configure helmet
PARTIAL BE FE ✓ AC-ORD-013 [CO] IN_TREATMENT is only available for orders whose device type includes the treatment phase
NOT READY AC-ORD-037 [CO] Device categories and types are supported per the defined table
Step 2 — Submit, fabricate, deliver, fit
Step 3 — Enter treatment phase (FITTING → IN_TREATMENT)
PARTIAL BE FE ✓ AC-ORD-105 [CO] Treatment phase: FITTING → IN_TREATMENT → COMPLETE after treatment completion signal
Step 4 — Treatment completion
NOT READY AC-ORD-098 [BOTH] Orders with treatment phase require treatment completion signal for completion
Edge Cases
NOT READY AC-ORD-103 [CO] Completion displays a soft warning for orders with treatment phase when treatment duration is below a configurable minimum. The default minimum is device-type-aware (e.g., 14 days for cranial helmets, 6 months for scoliosis braces) — not a single organisation-level default
PARTIAL BE FE ✓ AC-ORD-077 [CPO] Paediatric orders inherit guardian patient information acknowledgment from the patient record
Pre-prescription production path (clinical urgency — cranial helmets)
READY BE ✓ FE ✓ AC-ORD-110 [CPO] When the CPO determines clinical urgency for a patient, they can move an order from DRAFT to AWAITING_PRESCRIPTION with a documented justification. Available for any device type
NOT READY AC-ORD-111 [CPO] A prepayment (deposit) can be recorded on the order in AWAITING_PRESCRIPTION status — amount, timestamp, user captured
READY BE ✓ BE-only AC-ORD-112 [CPO] From AWAITING_PRESCRIPTION, a CPO, Production Manager, or Org Admin can click "Send to Production" to release the order to `READY_FOR_PRODUCTION` and start fabrication before the prescription arrives. Path D self-pay payment must still be confirmed
NOT READY AC-ORD-113 [CPO] When the Clinical Prescription and Reimbursement Prescription arrive, they are linked to the order. A prescription-configuration consistency check fires automatically
NOT READY BE AC-ORD-114 [CPO] The payment path transitions from D (self-pay) to A or B (insurance covers fully or partially). For D→A: prepayment returned — amount, timestamp, user, and reason recorded. For D→B on AWAITING_PRESCRIPTION orders: production continues, `patientInformed` re-capture becomes a fitting prerequisite
PARTIAL BE ✓ FE AC-ORD-115 [BOTH] The device cannot be fitted to the patient (FITTING blocked) until the prescription is linked and verified
#4 Path C Non-Standard Device 1/19 5%
Step 1 — Configure and select Path C
NOT READY FE AC-ORD-082 [CPO] Path C captures standard alternative, recommended device, clinical justification, and payer approval status
NOT READY BE AC-ORD-084 [CO] The platform generates a Path C proposal document from existing order data — no separate data entry
NOT READY AC-ORD-091 [CPO] Path C proposal document includes exactly the fields listed in the Proposal Contents table — no more, no less
Step 2 — Submit proposal (DRAFT → PENDING_APPROVAL)
NOT READY AC-ORD-021 [CPO] PENDING_APPROVAL is only available for Path C orders — Paths A, B, and D follow the standard core flow (DRAFT → READY_FOR_PRODUCTION via "Send to Production")
NOT READY AC-ORD-022 [CPO] Orders in PENDING_APPROVAL are not visible to production staff
NOT READY AC-ORD-092 [CPO] Path C proposal reference copy is retained as an order attachment subject to 10-year MDR retention
Step 3 — Payer decision
NOT READY FE AC-ORD-083 [CPO] Path C requires external payer approval before the order can be submitted to production
NOT READY FE AC-ORD-085 [CPO] CPO can record payer approval (with reference) or denial on a Path C order
NOT READY AC-ORD-023 [CPO] CPO can move a PENDING_APPROVAL order to READY_FOR_PRODUCTION (approved) or back to DRAFT (denied)
Step 4 — Payer data sharing disclosure and completion
NOT READY AC-ORD-093 [CPO] Payer data sharing disclosure is documented on the order (timestamp, user, notice version) before Path C proposal generation
NOT READY AC-ORD-094 [CPO] Path C proposal submission operates under GDPR Art 6(1)(c) legal obligation — no consent gate blocks proposal generation
NOT READY AC-ORD-095 [CPO] Confirming payer data sharing disclosure is a single CPO action — the system records timestamp, authenticated user, and active template version
Edge Cases
NOT READY AC-ORD-024 [CPO] If substantive configuration is modified while in PENDING_APPROVAL, the order reverts to DRAFT and the pending approval is invalidated
NOT READY AC-ORD-025 [CPO] When a Path C denial is resolved, all original Path C data (clinical justification, proposal, denial reference) is retained
NOT READY AC-ORD-026 [CPO] Switching from denied Path C to self-pay (Path B) requires fresh patient financial consent documentation
NOT READY DEFERRED AC-ORD-097 [CPO] Path C approval expiry (`approvalValidUntil`) generates a soft warning at submission when expired — not a hard block. CPO can override with documented acknowledgement
NOT READY AC-ORD-096 [CPO] If the self-pay amount changes after patient financial consent is confirmed, the consent is invalidated and must be re-captured
PARTIAL BE ✓ FE AC-ORD-101 [CPO] Submission prerequisites verify that Path B/C `patientInformed` confirmation is current
READY BE ✓ FE ✓ AC-ORD-102 [CPO] Submission prerequisites treat expired Path C approval as a soft warning, not a hard block
#5 Repair/Maintenance Order 0/7 0%
Step 1 — Assess device issue and proceed to service specification
PARTIAL BE ✓ FE AC-ORD-050 [CPO] Repair orders can be created referencing an existing completed order
NOT READY AC-ORD-051 [CPO] Maintenance orders can be created referencing an existing completed order with manufacturer service interval documented
NOT READY AC-ORD-059 [CO] Warranty status (ACTIVE, EXPIRING_SOON, EXPIRED) is computed and displayed per component
Step 2 — Incident flagging
NOT READY AC-ORD-054 [CO] Every repair, maintenance, adjustment, and reclamation order includes an incident flag
NOT READY AC-ORD-055 [CPO] CONFIRMED_INCIDENT flag triggers a notification to the Compliance area
Step 3 — Fabricate, deliver, complete
NOT READY AC-ORD-060 [CPO] Service history shows all events chronologically per device
NOT READY AC-ORD-061 [CPO] Service history records are append-only and cannot be deleted
#6 Adjustment Order 1/6 17%
Step 1 — Assess clinical change and proceed to adjustment
NOT READY AC-ORD-056 [CO] Adjustment orders require a prescription, a focused clinical visit, and a `parentOrderId`
NOT READY AC-ORD-058 [CO] The adjustment reason (anatomical change, activity level change, other clinical) is captured
Step 2 — Modify configuration
NOT READY AC-ORD-057 [CO] Adjustment orders load the parent order's configuration in the configurator as a starting point
NOT READY AC-ORD-031 [CPO] ADJUSTMENT orders follow the core flow only — no test device phase, no treatment phase
Step 3 — Submit and fabricate
Edge Cases
NOT READY AC-ORD-054 [CO] Incident flag is available on adjustment orders for safety signal capture
READY BE ✓ BE-only DEP AC-ORD-009 [CPO] Component modifications are logged with what changed, clinical reasoning, timestamp, and user
#7 Reclamation (Warranty Claim) 0/6 0%
Step 1 — Evaluate defective component and validate warranty
NOT READY AC-ORD-059 [CO] Warranty status (ACTIVE, EXPIRING_SOON, EXPIRED) is computed and displayed per component
Step 2 — Proceed to reclamation
NOT READY AC-ORD-052 [CPO] Reclamation orders validate warranty status before creation
NOT READY AC-ORD-054 [CO] Incident flag is available for safety signal capture
Step 3 — Fabricate replacement and complete
NOT READY AC-ORD-060 [CPO] Service history shows all events chronologically per device
Edge Cases
NOT READY be_implemented AC-ORD-053 [CPO] Reclamation creation is blocked for components with expired warranty
NOT READY AC-ORD-055 [CPO] CONFIRMED_INCIDENT flag triggers notification to Compliance
#8 Role-Based Data Visibility 1/11 9%
Patient PII visibility
NOT READY AC-ORD-070 [CPO] Role-based visibility is enforced per the matrix — technicians see no patient PII
NOT READY AC-ORD-075 [CPO] Notifications contain order references only — no patient data in email or push
Pricing visibility
READY BE ✓ FE ✓ AC-ORD-089 [CPO] Pricing is visible to clinical, admin, billing, and management roles
PARTIAL BE ✓ FE AC-ORD-090 [CPO] Pricing is hidden from production, technician, and logistics roles
Payer data visibility
NOT READY AC-ORD-072 [CPO] Payers see identity and claims data — no clinical images or scans (measurements are shared for medical necessity justification)
Compliance data
NOT READY AC-ORD-074 [CPO] Order data is retained for 10 years per MDR retention requirement
PARTIAL BE FE ✓ AC-ORD-077 [CPO] Paediatric orders inherit guardian patient information acknowledgment from the patient record
Search and dashboard visibility
NOT READY AC-ORD-111 [CPO] Search results respect role-based visibility
NOT READY AC-ORD-116 [CPO] Role-specific dashboards show relevant information per the defined views
Edge Cases
NOT READY AC-ORD-168 [CPO] Production staff see an order's fabrication-relevant attachments with patient PII stripped
PARTIAL BE ✓ FE AC-ORD-115 [CPO] Email and push notifications contain order references only — no patient data
#9 Transition Prerequisites and Traceability Verification 1/15 7%
Order creation — device-type selection
NOT READY AC-ORD-091 [BOTH] The order is created with a patient link at device-type selection. Visit links and the IE entry on the order are populated as the evaluation is completed; prescriptions are uploaded against the order before "Send to Production". The traceability chain is established from the start
NOT READY AC-ORD-099 [CO] Clinical context checks are device-type-aware — only fields required for the selected device type are verified at the evaluation
"Confirm device configuration" and "Send to Production"
NOT READY AC-ORD-092 [BOTH] "Confirm device configuration" verifies required components, no hard-block errors, required attachments, documented overrides, prescriber details, and payment path
PARTIAL BE ✓ FE AC-ORD-101 [CPO] "Send to Production" verifies that Path B/C `patientInformed` confirmation is current (timestamp later than most recent self-pay amount change)
READY BE ✓ FE ✓ AC-ORD-102 [CPO] "Send to Production" treats expired Path C approval (`approvalValidUntil`) as a soft warning, not a hard block
Completion — FITTING → COMPLETE / IN\_TREATMENT → COMPLETE
NOT READY AC-ORD-093 [BOTH] Completion verifies fitting documentation, PROs, serial numbers, traceability chain, and Annex XIII readiness
NOT READY AC-ORD-098 [CPO] Orders with treatment phase require treatment completion signal at completion
PARTIAL BE FE ✓ AC-ORD-100 [CPO] Completion serial number check applies to definitive device components only — test socket components are exempt
NOT READY AC-ORD-103 [CPO] Completion displays a soft warning for orders with treatment phase when treatment duration is below a configurable minimum
Cross-cutting prerequisite behaviour
NOT READY AC-ORD-094 [CPO] A broken traceability chain link blocks progression at submission and completion
NOT READY AC-ORD-095 [CPO] Clear feedback is provided when a prerequisite check fails, identifying the specific issue
NOT READY AC-ORD-142 [CPO] When a prerequisite check fails due to data owned by another area (e.g., incomplete visit, missing patient information record, expired prescription), the failure message identifies the specific gap and provides a direct link to the source record in the Patients area (e.g., "Visit incomplete: missing weight, height. Open visit")
NOT READY AC-ORD-096 [CPO] Transition evidence is recorded at submission and completion with timestamp, user, and check results
NOT READY DEFERRED AC-ORD-097 [CPO] Transition evidence is append-only and cannot be modified
NOT READY BE AC-ORD-076 [CPO] All Annex XIII required fields are present in the order data model
#10 Device Rejection at Fitting 3/11 27%
Step 1 — Device arrives at fitting
PARTIAL BE FE ✓ AC-ORD-100 [BOTH] Every device passes through FITTING before COMPLETE — no shortcut exists
PARTIAL BE ✓ FE AC-ORD-101 [CO] Fitting assessment can be recorded with fit evaluation, adjustments, and clinical notes
Step 2 — CPO rejects the device
PARTIAL BE FE ✓ AC-ORD-107 [CO] Device rejection at fitting sends the order back to IN_PRODUCTION with a documented reason
PARTIAL BE FE ✓ AC-ORD-027 [CPO] A device rejected at fitting returns to IN_PRODUCTION with a documented rejection reason
Step 3 — Component modifications during rework
NOT READY DEP AC-ORD-039 [CO] The configurator can be reopened during FITTING to swap components
READY BE ✓ BE-only DEP AC-ORD-009 [CPO] Component modifications during FITTING are logged with what changed, clinical reasoning, timestamp, and user
READY BE ✓ BE-only AC-ORD-036 [CPO] All component actions are logged with timestamp and user
Step 4 — Rework and return to fitting
PARTIAL BE ✓ FE AC-ORD-101 [CO] A new fitting assessment is recorded for the reworked device
READY BE ✓ FE ✓ AC-ORD-102 [CO] PROs are captured again at the second fitting
Edge Cases
PARTIAL BE ✓ FE AC-ORD-017 [CPO] Every status transition (FITTING → IN_PRODUCTION → FITTING) is logged
NOT READY AC-ORD-020 [CPO] Cancelled and rejected orders retain all data
#11 Configuration Override Flow 0/9 0%
Step 1 — Encounter validation warning
NOT READY BE AC-ORD-041 [CO] Clinical validity issues trigger soft warnings with override capability
NOT READY BE AC-ORD-043 [CO] Material conflicts (allergies) trigger soft warnings with override — not hard blocks
NOT READY BE AC-ORD-042 [CO] Mechanical compatibility violations trigger hard blocks with no override
NOT READY BE AC-ORD-040 [CO] Required components missing triggers a hard block preventing submission
Step 2 — Override with justification
NOT READY BE AC-ORD-044 [BOTH] Every override requires a justification and is logged with timestamp and user
NOT READY BE AC-ORD-045 [CPO] Override records are append-only and cannot be edited or deleted
Step 3 — Verify override in traceability chain
NOT READY AC-ORD-092 [BOTH] Submission prerequisites verify that all soft-warning overrides have documented justifications
Edge Cases
NOT READY AC-ORD-049 [CO] Each device type references the applicable GSPR conformity template
PARTIAL BE ✓ FE BE AC-ORD-038 [CO] The configurator works for device types with and without encoded component trees
⚙ Cross-Cutting Concerns 2/13 15%
Search and history
READY BE ✓ FE ✓ AC-ORD-110 [CPO] Orders can be searched by patient name, reference number, date range, status, device type, clinician, and order type
READY BE ✓ BE-only AC-ORD-112 [CPO] Order history per patient shows all orders chronologically
NOT READY AC-ORD-113 [CPO] Device history shows the complete lifecycle from creation through service
NOT READY BE AC-ORD-114 [CPO] Status change notifications are sent to the correct recipients per the notification table
NOT READY AC-ORD-117 [CPO] Recent orders are accessible without searching
Order lifecycle scope for cross-area consumers
NOT READY DEFERRED AC-ORD-130 [CPO] Terminal order states are COMPLETE and CANCELLED. All other statuses are non-terminal. Cross-area checks (organisation termination per AC-ORG-152, unit deactivation per AC-ORG-068) use this definition to determine whether outstanding orders exist
NOT READY DEFERRED AC-ORD-131 [CPO] An order in a CPO-dependent status (FITTING, FITTING, IN_TREATMENT) can be progressed by any active CPO assigned to the same unit — not only the CPO who created the order
Cancellation and rejection
NOT READY AC-ORD-018 [CPO] Cancellation requires a reason
NOT READY AC-ORD-019 [CPO] Rejected orders can be revised and resubmitted
NOT READY AC-ORD-020 [CPO] Cancelled and rejected orders retain all data
NOT READY AC-ORD-028 [CPO] A rejected order can be returned to DRAFT by the CPO for revision and resubmission
PARTIAL BE ✓ FE BE AC-ORD-029 [CPO] MDR-critical status transitions require mandatory notes documenting the clinical decision rationale
NOT READY SPEC AC-ORD-030 [CPO] An on-hold order can be rejected directly without returning to READY_FOR_PRODUCTION first

Component Trees

2 ready 11 partial 99 not ready 112 total
#1 CPO Configures a New AFO — Tree Evaluation End-to-End 0/31 0%
Step 1 — CPO selects device type
NOT READY AC-CTE-001 [BOTH] Device hierarchy presents category → type → variant navigation
NOT READY DEFERRED AC-CTE-002 [CO] All six device categories are structurally present in the hierarchy: Lower Limb Orthotic, Upper Limb Orthotic, Lower Limb Prosthetic, Upper Limb Prosthetic, Cranial, Spinal. Four categories have published trees at WHX (Lower Limb Orthotic, Lower Limb Prosthetic, Cranial, Spinal); Upper Limb Orthotic and Upper Limb Prosthetic are visible but have no published trees yet
NOT READY AC-CTE-003 [CPO] Selecting a variant loads the published tree version for that variant
NOT READY AC-CTE-004 [CPO] If only one variant exists for a type, variant selection is skipped
Step 2 — Bilateral handling (if bilateral device)
NOT READY AC-CTE-022 [CO] Bilateral device creates paired configurations — left and right — with the default bilateral mode (mirror or independent) coming from the tree definition per position, not from user choice
NOT READY AC-CTE-023 [CO] Mirror behaviour copies selections from primary side to secondary side — default for orthotic positions where both sides typically use the same components
NOT READY AC-CTE-024 [CO] Independent behaviour allows different selections per side — default for prosthetic positions where residual limbs differ. Note: bilateral prosthetic devices use separate orders (one per side) per BR-PROS-006, not paired configurations within one order. The bilateral handling in AC-CTE-022 through AC-CTE-025 applies to orthotic bilateral configurations
NOT READY AC-CTE-025 [CO] CPO can switch between mirror and independent at any point — switching from independent to mirror warns that the secondary side's selections will be replaced by the primary side's, and requires confirmation before proceeding
Step 3 — Tree loads and pre-fill fires
NOT READY AC-CTE-005 [BOTH] The configurator displays all component positions for the selected device type, each clearly indicating whether it is required, optional, or conditionally dependent on another selection
NOT READY AC-CTE-006 [CO] Pre-fill recommendations populate based on patient clinical data from the linked visit — weight, height, activity level, pathology
NOT READY partial_scope AC-CTE-007 [CPO] Pre-fill sources layer in priority order: visit data overrides previous device history — when sources conflict, the higher-priority source wins. Organisation preferences and Pentla defaults add two further layers below previous device history (deferred)
NOT READY AC-CTE-008 [CO] Previous device manufacturer ranks higher in suggestions but does not lock the selection
NOT READY AC-CTE-009 [CPO] Pre-fill populates all positions before the CPO begins interacting with the configurator — there is no visible loading state for pre-fill results after the tree appears
Step 4 — CPO reviews and modifies components
NOT READY AC-CTE-010 [BOTH] Every pre-filled value can be changed, removed, or swapped by the CPO — pre-fill is recommendation, never constraint
NOT READY AC-CTE-011 [CO] Available products for each position come from the organisation's component catalog, filtered by component category
NOT READY AC-CTE-012 [CPO] Preferred catalog entries rank higher in the selection list
PARTIAL BE ✓ FE AC-CTE-013 [CPO] Each component shows its reimbursement code
NOT READY AC-CTE-109 [CPO] Component specifications in the configurator (size, weight class, load rating) display in the organisation's configured measurement system (metric/imperial per AC-ORG-202). Changing the org preference affects display only — stored specifications retain their original units
NOT READY AC-CTE-014 [CO] Selecting a component that triggers a conditional dependency immediately updates affected positions — e.g., selecting an articulated shell requires a hinge
NOT READY AC-CTE-015 [CO] When a component selection triggers a dependency, the configurator responds correctly: required positions appear, excluded positions are removed, recommended positions show a suggestion, and default-value positions are pre-populated — each response matches clinical expectation for the device type
NOT READY AC-CTE-016 [CPO] Changing a component updates only visibly affected positions — unrelated positions remain unchanged
NOT READY AC-CTE-017 [CPO] When the CPO changes a component, dependency and validation updates appear without a visible loading state — affected positions update immediately
PARTIAL BE ✓ FE AC-CTE-018 [CO] Compatibility rules check physical constraints between selected products — e.g., adapter type mismatch between knee and pylon
NOT READY AC-CTE-019 [CO] Hard blocks prevent submission for physical impossibilities — the affected positions display the specific incompatibility (e.g., "selected knee requires 4-hole adapter, selected pylon has tube-clamp adapter") and the CPO can continue configuring other positions while the conflict exists
NOT READY AC-CTE-020 [CO] Soft warnings allow submission with documented clinical justification — the justification field appears in-context at the warning, not on a separate screen
NOT READY AC-CTE-021 [CPO] Positions without a selection do not trigger compatibility warnings — the CPO is not warned about a conflict until both relevant components are selected
Step 5 — Full validation on submission
NOT READY AC-CTE-026 [BOTH] Full validation pass runs at submission: all positions checked, all dependencies verified, all compatibility rules evaluated
NOT READY AC-CTE-027 [CPO] Every position shows a validation status — including valid ones
NOT READY AC-CTE-028 [CPO] Hard blocks prevent submission; soft warnings allow submission with override
Step 6 — Save and resume (edge case)
NOT READY AC-CTE-029 [CPO] Reopening a saved draft re-evaluates the full tree against saved selections using the pinned tree version
NOT READY AC-CTE-030 [CPO] Re-evaluation catches catalog changes since the draft was saved — deactivated products flagged
#2 CPO Configures a Transfemoral Prosthesis — Complex Tree 0/12 0%
Step 1 — Device type selection and pre-fill
NOT READY AC-CTE-031 [CO] Transfemoral prosthesis tree loads with all expected positions: socket assembly (socket shell, socket adapter), liner, knee unit (with proximal/distal adapters, charging dock, battery charger), pylon, functional adapter, foot, ankle adapter, suspension (with socket valve, vacuum pump, suspension sleeve, auxiliary belt), cosmetic cover, stump socks, protective sleeve
NOT READY AC-CTE-032 [CO] K-level from visit pre-fills appropriate knee unit categories — K2 sees fluid-controlled (default), polycentric, and microprocessor; K3 sees microprocessor ranked first and fluid-controlled; K4 sees microprocessor (default) with fluid-controlled and polycentric alternatives
NOT READY AC-CTE-033 [CO] Patient weight pre-fills load-rated components within safe range across all eight weight-validated components (socket adapter, knee unit, knee proximal/distal adapters, pylon, functional adapter, ankle adapter, foot)
Step 2 — Knee unit cascade
NOT READY AC-CTE-034 [CO] Selecting a specific knee unit triggers adapter compatibility check on pylon and cascade to charging dock and battery charger (microprocessor) or exclusion (mechanical, fluid-controlled)
NOT READY AC-CTE-035 [CO] If selected pylon adapter is incompatible with the knee unit, a hard block appears at both affected positions — the CPO can continue configuring other positions and resolve the mismatch before submission
NOT READY AC-CTE-036 [CO] Changing the knee unit re-evaluates charging dock, battery charger, and adapter chain dependencies
Step 3 — Free-form entry for unlisted product
NOT READY AC-CTE-037 [CPO] CPO can enter an unlisted product for any position using free-form entry
NOT READY AC-CTE-038 [CO] Free-form entries are subject to the same compatibility validation as catalog entries
NOT READY AC-CTE-039 [CPO] Free-form entries are per-order and do not enter the catalog automatically
Step 4 — Component swap during fitting
NOT READY AC-CTE-040 [CO] During `FITTING` or FITTING status, the same evaluation logic applies — validation rules do not change. Components used during test fitting may be temporary clinic stock (e.g., a demo knee for gait evaluation) and are distinguished from definitive selections in the final BoM
NOT READY AC-CTE-041 [CO] Swapping a component during fitting triggers the same dependency re-evaluation
Step 5 — Variant with multiple activity variants (edge case)
NOT READY DEFERRED AC-CTE-045 [CO] Transtibial prosthesis variants (temporary, definitive, swimming, sports) are separate device configurations, each with its own tree — a patient may have multiple active prostheses for different stages or activities, ordered independently
#3 Pentla Domain Expert Authors and Publishes a New Tree Version 0/22 0%
Step 1 — Create a draft
NOT READY AC-CTE-046 [CPO] Domain expert can create a draft from an existing published version (copy) or from scratch
NOT READY AC-CTE-047 [CPO] Only one draft may exist per device variant at any time
Step 2 — Edit positions and rules
NOT READY AC-CTE-048 [CO] Domain expert can add, remove, and reorder positions in the hierarchy
NOT READY AC-CTE-049 [CPO] Position codes must be unique within the tree version — duplicates are rejected immediately
PARTIAL BE ✓ FE AC-CTE-050 [CPO] Every tree must have exactly one root position
NOT READY AC-CTE-051 [CPO] Position hierarchy must be acyclic — cycle detected immediately during editing
Step 3 — Add conditional dependencies and compatibility rules
PARTIAL BE ✓ FE AC-CTE-052 [CO] Domain expert can define conditional dependencies between positions with trigger conditions and effects
NOT READY AC-CTE-053 [CPO] Dependency trigger and target must belong to the same tree version
NOT READY AC-CTE-054 [CPO] Compatibility rule positions must belong to the same tree version
Step 4 — Authoring validation (continuous)
NOT READY AC-CTE-055 [CPO] When a domain expert adds or edits a position, structural constraint violations (duplicate codes, cycles, missing root) are flagged at the point of the edit — no separate validation step is needed to discover them
PARTIAL BE ✓ FE AC-CTE-056 [CPO] Component categories must reference the global registry — unrecognised categories are rejected
Step 5 — Testing sandbox
NOT READY AC-CTE-057 [CPO] Domain expert can run the evaluation engine against the draft version with test clinical data
NOT READY AC-CTE-058 [CPO] Testing sandbox uses a test catalog, not a real organisation's catalog
NOT READY DEFERRED AC-CTE-059 [CPO] Test scenarios can be saved and replayed for regression testing (deferred)
Step 6 — Publish-time checks
NOT READY AC-CTE-060 [CPO] Publish-time validation catches circular dependency chains
NOT READY AC-CTE-061 [CPO] Publish-time validation catches require + exclude conflicts on the same position
NOT READY AC-CTE-062 [CPO] Publish-time validation catches unreachable positions
Step 7 — Publish
NOT READY AC-CTE-063 [CPO] Publish workflow includes validation results, change description, and confirmation
NOT READY AC-CTE-064 [CPO] Previous published version is automatically deprecated when the new version is published
NOT READY AC-CTE-065 [CPO] Published versions cannot be rolled back — forward-fix only
Step 8 — In-progress orders unaffected (edge case)
NOT READY AC-CTE-066 [CPO] Orders created before the publish continue using their pinned version — no change in rules, validation, or available positions
NOT READY AC-CTE-067 [CPO] New orders created after publish get the new version
#4 Organisation Admin Manages Customer Extensions 2/11 18%
Step 1 — Create an extension
NOT READY AC-CTE-068 [CPO] Org admin can create all five extension types: add position, hide position, modify pre-fill, add conditional dependency, add compatibility rule
NOT READY AC-CTE-069 [CPO] Extensions are organisation-scoped — invisible to other organisations
Step 2 — Hide required position (edge case: blocked)
NOT READY AC-CTE-070 [CPO] Hiding a required position is blocked unless a conditional dependency adjusts its classification — the block message identifies the position's required classification and explains that a conditional dependency must change it before hiding is allowed
Step 3 — Preview and activate
NOT READY AC-CTE-071 [CO] Org admin can preview the combined effect of tree + extensions before activation
NOT READY AC-CTE-072 [CPO] Extension approval workflow is configurable — optional per organisation
Step 4 — Extension snapshot on order creation
NOT READY AC-CTE-073 [CPO] When a CPO creates an order, active extensions are snapshotted alongside the tree version
PARTIAL BE ✓ FE AC-CTE-074 [CPO] Extension snapshots are complete copies — subsequent extension changes do not affect in-flight orders
Step 5 — New tree version triggers migration
READY BE ✓ BE-only integration AC-CTE-075 [CPO] When Pentla publishes a new tree version, org admin receives a migration notification listing affected extensions
PARTIAL BE ✓ FE AC-CTE-076 [CPO] New orders use the new tree version without extensions until migration is complete
Step 6 — Migration review
READY BE ✓ BE-only AC-CTE-077 [CPO] Org admin reviews each extension against the new tree version — some may apply cleanly, others may need adjustment. The migration interface pre-classifying each extension as compatible, needs review, or obsolete is a deferred enhancement
Step 7 — Extension deactivation
NOT READY AC-CTE-078 [CPO] Deactivating an extension does not affect orders that already captured it in their snapshot
#5 Organisation Admin Manages Component Catalog 0/13 0%
Step 1 — Create and manage catalogs
NOT READY AC-CTE-079 [CPO] Org admin can create, activate, and deactivate catalogs
NOT READY AC-CTE-080 [CPO] Catalogs are organisation-scoped — invisible to other organisations
Step 2 — Add catalog entries
NOT READY AC-CTE-081 [CPO] Catalog entries capture: product identity, component category, technical specifications, compatibility tags, pricing, reimbursement code, preference flag, reference material
NOT READY AC-CTE-082 [CPO] Component category must reference the global registry — unrecognised categories are rejected
Step 3 — Inactive entry handling
NOT READY AC-CTE-083 [CPO] Inactive entries are excluded from new configurations
NOT READY AC-CTE-084 [CPO] Inactive entries are retained for historical reference on existing orders
NOT READY AC-CTE-110 [CPO] When a CPO reopens the configurator for a DRAFT order and a previously-selected component's catalog entry has been deactivated since the draft was saved, the affected position displays a "no longer available" indicator on the deactivated component. The CPO must replace the deactivated component before the order can leave DRAFT — deactivated components are a hard block on the DRAFT → READY_FOR_PRODUCTION transition
Step 4 — Bulk import
NOT READY AC-CTE-085 [CPO] Bulk import validates entries, flags duplicates, and reports errors
NOT READY AC-CTE-086 [CPO] Import adds entries but does not update or delete existing entries
Step 5 — Free-form entry promotion
NOT READY AC-CTE-087 [CPO] Catalog management shows free-form entries awaiting review
NOT READY AC-CTE-088 [CPO] Org admin can promote a free-form entry to a full catalog entry
Step 6 — Catalog usage statistics
NOT READY DEFERRED AC-CTE-089 [CPO] Catalog management shows usage statistics for entries (deferred)
Step 7 — Required position coverage check
NOT READY AC-CTE-090 [CPO] Every required position in active trees must have at least one matching catalog entry — warned at tree activation
#6 Tree Version Update with In-Progress Orders 0/10 0%
Step 1 — Orders exist using current tree version
NOT READY AC-CTE-042 [CPO] The order records which tree version was active at draft creation
NOT READY AC-CTE-043 [CPO] The order uses that pinned version through its entire lifecycle
NOT READY AC-CTE-091 [CPO] Orders in DRAFT, IN_PRODUCTION, FITTING — all pinned to the current published tree version
Step 2 — Domain expert publishes new version
NOT READY AC-CTE-092 [CPO] New version is published — previous version is deprecated
Step 3 — In-progress orders continue unchanged
NOT READY AC-CTE-093 [CPO] DRAFT order reopened: tree rules, positions, and validation are identical to before the publish
NOT READY AC-CTE-111 [CPO] When a CPO reopens a DRAFT order that uses a deprecated tree version, the configurator displays an informational notice indicating the order uses an older tree version and new orders would use the current version. The notice does not block — the CPO can continue working on the order without action
NOT READY AC-CTE-094 [CPO] FITTING order: component swap uses the pinned version's rules
Step 4 — New order gets new version
NOT READY AC-CTE-095 [CPO] A new order created after publish loads the new tree version
Step 5 — Audit trail integrity
NOT READY AC-CTE-044 [CPO] An auditor can see the exact tree version, extension snapshot, and all evaluation results for any historical order
NOT READY AC-CTE-096 [CPO] Auditor reviewing the in-progress order sees the original tree version and its rules — not the new version
#7 Reimbursement Codes and Multi-Jurisdiction 0/5 0%
Step 1 — Reimbursement codes are Pentla-managed
PARTIAL BE ✓ FE AC-CTE-097 [CPO] Reimbursement codes are shared across all organisations in a jurisdiction
Step 2 — Jurisdiction determines codes
PARTIAL BE ✓ FE AC-CTE-098 [CPO] The unit's jurisdiction determines which reimbursement codes apply — not the organisation's home country
PARTIAL BE ✓ FE AC-CTE-099 [CPO] A multi-jurisdiction organisation sees different codes depending on which unit the order belongs to
Step 3 — Codes visible in configurator
PARTIAL BE ✓ FE AC-CTE-100 [CO] Each component in the configurator displays its reimbursement code
Step 4 — Historical code retention
NOT READY AC-CTE-101 [CPO] When reimbursement codes are updated, historical orders retain the codes that were in effect at order creation
#8 Device Type Examples — Clinical Accuracy Spot-Check 0/8 0%
Step 1 — AFO tree accuracy
NOT READY SPEC AC-CTE-102 [CO] Solid AFO tree: shell (with proximal trim as specification), footplate, posterior strap, calf cuff, instep strap (conditional — deep-shell override), padding, liner (conditional on laminated fabrication at DEVICE level), lateral/medial support (per-side valgus/varus, valid across bilateral pairs), T-strap (conditional on tibial torsion), growth margin (conditional on paediatric), rocker bottom, sole insert — positions, per-side alignment rules, and clinical workflow order are clinically accurate
NOT READY SPEC AC-CTE-103 [CO] Articulated AFO tree: hinge selection triggers appropriate ankle joint dependencies
Step 2 — Prosthetic tree accuracy
NOT READY SPEC AC-CTE-104 [CO] Transtibial prosthesis: socket assembly (socket shell, socket adapter), liner, suspension (11 types: PASSIVE_SUCTION, ACTIVE_SUCTION, SAS, HYBRID_LOCK, PIN_LOCK, LANYARD, SUPRACONDYLAR, SUPRACONDYLAR_CUFF, ANATOMIC, CUFF_STRAP, FIGURE_EIGHT_STRAP — with bidirectional liner-suspension rules), functional adapter, pylon, foot, ankle adapter — positions, dependencies, and clinical workflow order are clinically accurate
NOT READY SPEC AC-CTE-105 [CO] Transfemoral prosthesis: socket assembly (socket shell, socket adapter), liner, suspension (7 types: PASSIVE_SUCTION, ACTIVE_SUCTION, SAS, HYBRID_LOCK, PIN_LOCK, LANYARD, KISS — with suspension sleeve, socket valve, vacuum pump, auxiliary belt, and bidirectional liner rules), knee unit (4 types with charging dock/battery charger cascade), functional adapter, pylon, foot, ankle adapter — positions, dependencies, and clinical workflow order are clinically accurate
NOT READY SPEC AC-CTE-112 [CO] Knee disarticulation prosthesis: socket assembly (socket shell, socket adapter, socket windows conditional on condyle prominence at DEVICE level), liner, suspension (6 types: ANATOMIC, PASSIVE_SUCTION, ACTIVE_SUCTION, SAS, LANYARD, KISS — with suspension sleeve, socket valve, vacuum pump, auxiliary belt, and bidirectional liner rules), knee unit (3 polycentric types with charging dock/battery charger cascade for microprocessor), functional adapter, pylon, foot, ankle adapter — positions, dependencies, condyle prominence as primary structural classifier, and clinical workflow order are clinically accurate
Step 3 — Cranial helmet accuracy
NOT READY SPEC AC-CTE-106 [CO] Protective helmet: shell (fabrication method, and method-specific attributes — shell colour + design pattern + optional vapor smoothing finish for 3D-printed, transfer paper (First Choice and Backup Choice — both required before the order can move past DRAFT; 'Pick pattern later' is a tickbox that lets the CPO keep working on the rest of the order without warnings while parents decide, but it doesn't skip the requirement) for thermoplastic), comfort padding (single spec: coverage, material, thickness, colour, protective layer, and method-specific perforation attribute — Padding Perforation for 3D-printed with Perforated default, Helmet Perforation for thermoplastic with Don't perforate default), closure (auto-selected by fabrication method), forehead protection and chin protection as optional additions — no node-visibility conditionals; perforated padding-material variants hidden from catalogue for thermoplastic
NOT READY SPEC AC-CTE-107 [CO] Corrective helmet: shell (fabrication method, and method-specific attributes — shell colour + design pattern + optional vapor smoothing finish for 3D-printed, transfer paper (First Choice and Backup Choice — both required before the order can move past DRAFT; 'Pick pattern later' is a tickbox that lets the CPO keep working on the rest of the order without warnings while parents decide, but it doesn't skip the requirement) for thermoplastic; shell designed around the patient's 3D scan with design file linked to order), padding (single spec: coverage, material, thickness, colour, and method-specific perforation attribute — Padding Perforation for 3D-printed with Perforated default, Helmet Perforation for thermoplastic with Don't perforate default; allergy-incompatible materials hidden from catalogue; perforated padding-material variants hidden from catalogue for thermoplastic; protective layer surfaced only when the atopic dermatitis clinical flag is set, then required as a hard rule with CPO selecting Microfibre or 3D Breathable fabric), closure (auto-selected by fabrication method), pathology classification (positional/synostotic with 11 variants — informs the CPO's shell design, does not drive configurator conditionals), clinical flags (hemangioma, atopic dermatitis, drainage, scar, birthmarks, glasses), device preview, and treatment phase with monthly progress reviews reflect clinical practice
Step 4 — Spinal accuracy
NOT READY SPEC AC-CTE-108 [CO] Cheneau TLSO: pressure zones, curve classification input, pad positioning — reflects scoliosis brace clinical practice

Component Catalogue

0 ready 24 partial 88 not ready 112 total
#1 Platform Admin Adds Products From a Manufacturer Catalogue 0/23 0%
Step 1 — Create product in the shared catalogue
PARTIAL BE ✓ FE AC-CAT-001 [CPO] Platform Admin can create a product entry in the shared catalogue with: manufacturer, product line, model name, SKU, component category, and technical specifications
NOT READY AC-CAT-002 [CPO] SKU must be unique across the entire shared catalogue — duplicate SKUs are rejected at creation
NOT READY AC-CAT-003 [CPO] Component category must reference the global component category registry — unrecognised categories are rejected
NOT READY AC-CAT-004 [CPO] Each product can have reference material: product image and link to manufacturer data sheet. At least one form of reference material is recommended but not required for product creation — many older or niche products lack accessible data sheets
Step 2 — Define size variants
NOT READY AC-CAT-005 [CO] A product entry supports a size variant table — each size has its own technical specifications (weight, build height, heel height, or other size-dependent values)
NOT READY AC-CAT-006 [CO] Size-specific specifications are available to the compatibility engine — e.g., a foot's build height at the patient's size is used for clearance validation, not the product's generic build height range
NOT READY AC-CAT-007 [CPO] Products without size variants (e.g., adapters with a single configuration) do not require a size variant table
Step 3 — Define bundled components (if applicable)
NOT READY AC-CAT-008 [CO] A product can declare "supplied with" relationships to other products — indicating that purchasing the main product includes the bundled components
NOT READY AC-CAT-009 [CO] Bundled components map to specific tree positions so the compatibility engine can validate their interfaces
NOT READY AC-CAT-010 [CPO] Bundled components are accounted for in pricing — the main product's price includes them, avoiding double-counting when the CPO selects the main product
NOT READY AC-CAT-095 [CPO] Bundled component relationships must be acyclic — a product cannot directly or transitively bundle itself
NOT READY AC-CAT-096 [CPO] Stocking the main product automatically makes its bundled components available in the configurator for the tree positions they fill — the org does not need to separately stock bundled sub-components
NOT READY AC-CAT-097 [BOTH] When a bundled sub-component enters SAFETY_RECALL, the main product is also excluded from new configurations — because the main product physically includes the recalled component
NOT READY AC-CAT-098 [CO] Bundled components do not have independent size variants — the manufacturer ships a specific sub-component configuration with the main product. If the main product has size variants, the bundled sub-components are fixed per size
NOT READY AC-CAT-099 [CO] The CPO can replace an auto-filled bundled component with a different product from the catalogue. The main product's price does not change (it reflects the assembly as sold). The replacement component is priced at its own catalogue price
NOT READY AC-CAT-100 [CPO] In the coverage report, tree positions that would be filled by a bundled sub-component of a stocked main product count as covered
Step 4 — Standard specifications per component category
NOT READY AC-CAT-011 [CO] Each component category defines a set of standard specification fields — these are structured (not free-text) and power pre-fill recommendations and compatibility validation
NOT READY AC-CAT-012 [CO] Standard specification fields for prosthetic feet include: activity level range, maximum user weight, stiffness categories with weight range mappings, build height, heel height
NOT READY AC-CAT-013 [CO] Standard specification fields for knee joints include: activity level range, maximum user weight, knee mechanism type, flexion range
NOT READY AC-CAT-014 [CO] Standard specification fields for adapters include: adapter interface type and size, material, build height, maximum patient weight
NOT READY AC-CAT-015 [CPO] Platform Admin can add custom specification fields beyond the standard set for a product when the standard fields do not cover manufacturer-specific attributes
Step 5 — Product activation
NOT READY AC-CAT-016 [CPO] A newly created product is ACTIVE by default — immediately available for organisations to stock
NOT READY AC-CAT-017 [CPO] All product changes are logged with who made the change and when
#2 Org Admin Selects Products and Enters Pricing — Onboarding 0/12 0%
Step 1 — Browse the shared catalogue
PARTIAL BE ✓ FE AC-CAT-018 [CPO] Org admin can browse the shared product catalogue organised by component category hierarchy
PARTIAL BE ✓ FE AC-CAT-019 [CPO] Org admin can filter by manufacturer, component category, and product status (active/discontinued)
PARTIAL BE ✓ FE AC-CAT-020 [CPO] Each product in the shared catalogue shows its full specifications, reference material, and whether the organisation currently stocks it
Step 2 — Select products to stock
PARTIAL BE ✓ FE AC-CAT-021 [CPO] Org admin can select a product from the shared catalogue and add it to their organisation's stock list
PARTIAL BE ✓ FE AC-CAT-022 [CPO] A product not in the organisation's stock list does not appear in that organisation's configurator — CPOs only see stocked products
Step 3 — Enter negotiated pricing
PARTIAL BE ✓ FE AC-CAT-023 [CPO] Org admin enters their negotiated unit price and currency for each stocked product
PARTIAL BE ✓ FE AC-CAT-024 [CPO] Pricing is organisation-scoped — one organisation's prices are never visible to another organisation
PARTIAL BE ✓ FE AC-CAT-025 [CPO] A stocked product without a price does not appear in the configurator and shows a "missing pricing" indicator on the org admin's catalogue management view — the admin must enter a price before CPOs can use the product
Step 4 — Mark preferred products
PARTIAL BE ✓ FE AC-CAT-026 [CPO] Org admin can mark stocked products as preferred — preferred products rank higher in the component picker. [post-WHX] Preferred products also rank higher in pre-fill recommendations once the organisation preferences layer is available. Preferred status is organisation-scoped — one organisation's preferences do not affect another
NOT READY AC-CAT-027 [CO] [post-WHX] Preferred status influences pre-fill: when the pre-fill engine selects between products that are clinically equivalent for the patient, preferred products rank first
Step 5 — Verify coverage
NOT READY AC-CAT-028 [CPO] Org admin can view a coverage report: which required tree positions have at least one matching stocked product and which do not
NOT READY AC-CAT-029 [CPO] Coverage gaps are visible on the admin's catalogue management view without requiring the admin to navigate to a separate report or trigger a manual refresh. Gap counts update when products are stocked, removed, or when a new tree version is published
#3 Org Admin Uploads Pricing Spreadsheet — Bulk Pricing Import 0/11 0%
Step 1 — Upload pricing file
NOT READY AC-CAT-030 [CPO] Org admin can upload a structured file (CSV or equivalent) mapping SKUs to negotiated unit prices
NOT READY AC-CAT-031 [CPO] The file format is defined by Pentla with clear column definitions — SKU and unit price are required, currency is optional (defaults to org's primary currency)
Step 2 — Validation
NOT READY AC-CAT-032 [CPO] Each row is validated: SKU must exist in the shared catalogue, price must be a valid positive number
NOT READY AC-CAT-033 [CPO] Rows with SKUs not found in the shared catalogue are flagged as errors — the product may need to be added by Pentla before the org can price it
NOT READY AC-CAT-034 [CPO] Rows with SKUs already in the org's stock list are treated as price updates — the new price replaces the existing price (with the previous price retained in history)
Step 3 — Preview before commit
NOT READY AC-CAT-035 [CPO] Before committing, the admin sees a summary: how many products will be newly stocked, how many prices will be updated, and how many rows have errors
NOT READY AC-CAT-036 [CPO] The admin can commit valid rows while setting aside error rows for correction
Step 4 — Commit
NOT READY AC-CAT-037 [CPO] Committing the import stocks the products (if not already stocked) and sets or updates their prices
NOT READY AC-CAT-038 [CPO] Newly stocked products appear in the organisation's configurator immediately after commit
Step 5 — Error correction
NOT READY AC-CAT-039 [CPO] Error rows can be corrected in-place and re-validated without re-uploading the entire file
NOT READY AC-CAT-040 [CPO] The import process is idempotent — re-uploading the same file produces the same result without creating duplicates
#4 CPO Searches Catalog During Configuration — Clinical Filter Flow 0/13 0%
Step 1 — Position context determines available products
PARTIAL BE ✓ FE AC-CAT-041 [BOTH] The component picker shows only products that match the position's component category AND are stocked by the CPO's organisation
PARTIAL BE ✓ FE AC-CAT-042 [CPO] If no stocked products match the position, the picker shows an empty state with guidance: "No products in your catalogue match this position. Add an unlisted component or contact your admin to update the catalogue"
Step 2 — Clinical filters as primary navigation
NOT READY AC-CAT-043 [CO] The component picker presents clinically relevant filters as the primary navigation — not name or SKU search. For prosthetic components, filters include: weight class, activity level, adapter interface type, and manufacturer
PARTIAL BE ✓ FE AC-CAT-044 [CO] Filters are contextual to the component category — prosthetic feet show stiffness category and heel height filters; knee joints show mechanism type; adapters show interface type and build height. The platform presents only the filters relevant to the current position's component category
PARTIAL BE ✓ FE AC-CAT-045 [CPO] Name and SKU search is available as a complement to clinical filters — for CPOs who already know which product they want
Step 3 — Browse and compare results
PARTIAL BE ✓ FE AC-CAT-046 [CO] Each product in the results shows: product name, manufacturer, key specifications for the category (weight class, activity level, stiffness), the organisation's negotiated price, reimbursement code, and a product image
PARTIAL BE ✓ FE AC-CAT-047 [CPO] Preferred products rank first in results, followed by non-preferred products
PARTIAL BE ✓ FE AC-CAT-048 [CPO] The CPO can view the manufacturer's data sheet for any product directly from the picker
Step 4 — Select product
PARTIAL BE ✓ FE AC-CAT-049 [CPO] Selecting a product populates the tree position with that product's specifications and compatibility tags
PARTIAL BE ✓ FE AC-CAT-050 [CO] Selection immediately triggers dependency resolution and compatibility validation for all affected positions
Step 5 — Select size (if product has size variants)
NOT READY AC-CAT-051 [CO] If the selected product has size variants, the CPO is prompted to select a size — the size selector shows size-specific specifications (weight, build height) for each available size
NOT READY AC-CAT-052 [CO] The compatibility engine uses the size-specific specifications for validation — not the product's generic specification range
PARTIAL BE ✓ FE AC-CAT-053 [CO] Pre-fill suggests a size based on the patient's measurements from the linked assessment when a clear mapping exists (e.g., contralateral foot length → prosthetic foot size)
#5 CPO Creates Free-Form Entry, Dual Promotion Path 0/14 0%
Step 1 — CPO creates free-form entry
NOT READY AC-CAT-054 [CO] When no suitable product exists in the component picker, the CPO can create a free-form entry for the current order by providing: manufacturer name, model name, component category, and category-relevant specifications
NOT READY AC-CAT-055 [CO] Free-form entries are subject to the same compatibility validation as catalogue products — specifications provided by the CPO are used for rule evaluation
NOT READY AC-CAT-056 [CPO] A free-form entry without a reimbursement code triggers a soft warning at submission — not a hard block. Clinical need takes priority over billing completeness
NOT READY AC-CAT-057 [CPO] Free-form entries are per-order — they do not automatically enter the organisation's stock list or the shared catalogue
Step 2 — Order proceeds with free-form entry
PARTIAL BE ✓ FE AC-CAT-058 [CPO] The order proceeds normally with the free-form entry occupying the tree position. The CPO enters a unit price for the free-form component on the order
Step 3 — Org admin reviews free-form entries
NOT READY AC-CAT-059 [CPO] Org admin sees a review queue of free-form entries created by CPOs that have not been promoted or dismissed
PARTIAL BE ✓ FE AC-CAT-060 [CPO] Each free-form entry in the queue shows: the number of orders that have used it, the CPO(s) who created it, the date of most recent use, and its specifications
PARTIAL BE ✓ FE AC-CAT-061 [CPO] Frequently used free-form entries surface higher in the review queue
Step 4 — Org admin promotes or dismisses
NOT READY AC-CAT-062 [CPO] Org admin can **promote** a free-form entry to the organisation's stock list — the admin must provide a negotiated price and fill in any specifications the CPO omitted
NOT READY AC-CAT-063 [CPO] Org admin can **dismiss** a free-form entry with a reason — the entry remains available on existing orders but is marked as reviewed
NOT READY AC-CAT-064 [CPO] Org admin can **merge** a free-form entry with an existing stocked product if the free-form entry is the same product under a different name or incomplete specification
NOT READY AC-CAT-065 [CPO] Promoting a free-form entry does not retroactively change orders that used the original free-form entry — those orders retain their per-order snapshot
Step 5 — Pentla reviews for shared catalogue addition
NOT READY AC-CAT-066 [CPO] Pentla can review free-form entries across all organisations to identify products that should be added to the shared catalogue
NOT READY AC-CAT-067 [CPO] When Pentla adds a previously free-form product to the shared catalogue, organisations that promoted the free-form entry locally can link their stock entry to the shared catalogue product
#6 Reimbursement Code Lifecycle 0/10 0%
Step 1 — Platform Admin manages reimbursement codes
PARTIAL BE ✓ FE AC-CAT-068 [CPO] Platform Admin can create reimbursement codes with: jurisdiction, code system, code value, description, component categories covered, maximum reimbursement (optional), and validity period
NOT READY AC-CAT-069 [CPO] Reimbursement codes are shared across all organisations in a jurisdiction
Step 2 — Jurisdiction determines applicable codes
NOT READY AC-CAT-070 [CPO] The unit's jurisdiction determines which reimbursement codes apply — not the organisation's home country
NOT READY AC-CAT-071 [CPO] A multi-jurisdiction organisation sees different codes depending on which unit the order belongs to
Step 3 — Dual reimbursement model
NOT READY AC-CAT-072 [BOTH] The platform supports per-component reimbursement codes (e.g., German GKV Positionsnummern where each component carries its own code)
NOT READY AC-CAT-073 [BOTH] The platform supports per-device-type budget ceilings (e.g., Slovenian ZZZS where the reimbursement prescription covers the device as a whole, not individual components) — the jurisdiction determines which model applies
NOT READY AC-CAT-074 [CPO] In per-component jurisdictions, each selected component displays its reimbursement code and amount in the configurator
NOT READY AC-CAT-075 [CPO] In per-device-type jurisdictions, the configurator displays the device-level budget ceiling and the running total of configured component costs against that ceiling
Step 4 — Code expiry and historical retention
NOT READY AC-CAT-076 [CPO] When a reimbursement code expires, a replacement code can be associated. Products referencing the expired code are flagged for the org admin to update
NOT READY AC-CAT-077 [CPO] Historical orders retain the reimbursement codes that were in effect at the time of order creation — code expiry or replacement does not retroactively change historical orders
#7 Safety Recall — FSCA Triggers Reverse-Lookup to Affected Patients 0/29 0%
Step 1 — Pentla marks product as safety recall
NOT READY AC-CAT-078 [CPO] Platform Admin can change a product's lifecycle state to SAFETY_RECALL — this immediately excludes the product from new configurations across all organisations
NOT READY AC-CAT-079 [CPO] SAFETY_RECALL is distinct from DISCONTINUED — it carries a safety urgency flag and a reference to the FSCA notice
Step 2 — Organisations are notified
NOT READY AC-CAT-080 [CPO] When a product is marked SAFETY_RECALL, all organisations that stock that product receive a notification identifying the product and the safety concern
Step 3 — Reverse-lookup: identify affected orders and patients
NOT READY AC-CAT-081 [BOTH] The platform can identify all orders that contain a recalled product — regardless of order status. This includes orders in every v1 lifecycle state: DRAFT, AWAITING_PRESCRIPTION, READY_FOR_PRODUCTION, IN_PRODUCTION, READY_FOR_FITTING, FITTING, TEST_SOCKET_IN_USE, IN_TREATMENT, COMPLETE, ON_HOLD, and CANCELLED. `[post-Leipzig]` PENDING_APPROVAL is also covered when that status ships
NOT READY AC-CAT-082 [BOTH] The reverse-lookup produces a list of affected patients with their order references, enabling the organisation to fulfil its vigilance obligations under MDR Articles 87–92
Step 4 — Org admin reviews affected orders
NOT READY AC-CAT-083 [CPO] For orders in DRAFT status, the recalled product is flagged and must be replaced before submission — the order cannot pass the submission prerequisites with a recalled component
NOT READY AC-CAT-092 [BOTH] For orders in READY_FOR_PRODUCTION or IN_PRODUCTION status, the recalled product is flagged and the organisation is prompted to determine whether the device can be modified (substitute the component) or must be scrapped
NOT READY AC-CAT-093 [BOTH] For orders in FITTING or TEST_SOCKET_IN_USE, the recalled product is flagged with a safety warning — the CPO must not fit the patient with a device containing the recalled component without a risk assessment
NOT READY AC-CAT-084 [CPO] For delivered or completed orders, the recalled product is flagged in the order history for traceability — the historical record is not altered
NOT READY AC-CAT-094 [CPO] The submission prerequisites checks product lifecycle state at submission time — a product that was ACTIVE at configuration but SAFETY_RECALL at submission is blocked
Catalog data model edge cases
NOT READY AC-CAT-085 [CPO] A product with no active stocking by any organisation is still visible in the shared catalogue — it exists as a reference even if no organisation currently carries it
NOT READY AC-CAT-086 [CO] When a product is DISCONTINUED, organisations that still stock it see a "discontinued" indicator. The product remains usable for in-flight orders but is excluded from new configurations
NOT READY AC-CAT-087 [CPO] A product can be re-activated from DISCONTINUED if the manufacturer resumes production. SAFETY_RECALL products cannot be re-activated without explicit Pentla review
Product data integrity edge cases
NOT READY AC-CAT-102 [CPO] When a Platform Admin edits a product's specifications in the shared catalogue, in-flight orders retain the specifications at configuration time — only new configurations pick up the updated values
NOT READY AC-CAT-103 [CPO] SKU cannot be changed after product creation — if a manufacturer changes their SKU scheme, a new product is created and the old one is discontinued
NOT READY AC-CAT-104 [CPO] Products in the shared catalogue are never hard-deleted — lifecycle state transitions are the only removal mechanism
Pricing edge cases
NOT READY AC-CAT-088 [CPO] When an org admin removes a product from their stock list, in-flight orders that already selected that product retain the selection and price at the time of configuration
NOT READY AC-CAT-089 [CPO] When an org admin updates a product's price, in-flight orders retain the price at configuration time. Only new selections pick up the updated price
Component category edge cases
NOT READY AC-CAT-101 [CPO] Component categories cannot be removed from the global registry if any product or tree position references them
System height and clearance
NOT READY AC-CAT-105 [CO] Structural prosthetic components (feet, adapters, knee joints, pylons) have system height specified as min and max values — the compatibility engine sums all selected components' system heights and compares the total against the patient's available clearance
NOT READY AC-CAT-106 [CO] Components with adjustable length (e.g., tube adapters that can be shortened) reflect this range in their min/max system height values
Activity level normalisation
NOT READY AC-CAT-107 [CO] Products from manufacturers using different activity classification systems (K-levels, mobility grades, impact levels) are normalised to K-levels (K1–K4) in the shared catalogue — the clinical filter in the component picker shows K-levels regardless of manufacturer terminology
Per-activity-level weight ratings
NOT READY AC-CAT-108 [BOTH] When a manufacturer provides tiered maximum user weight ratings by activity level, the compatibility engine checks the weight limit for the patient's actual activity level — not just the generic maximum. A product rated 136 kg at K3 but 110 kg at K4 must warn when selected for a 130 kg K4 patient
Multi-position products
NOT READY AC-CAT-109 [CO] A multi-position product (e.g., an integrated limb system spanning knee + ankle + foot) fills multiple tree positions simultaneously when selected — sub-positions become locked and cannot be independently modified
NOT READY AC-CAT-110 [CPO] Multi-position products have a single price covering all positions they span — each sub-position does not carry a separate price
Material-type components for helmets and orthotics
NOT READY AC-CAT-111 [CO] The shared catalogue includes material-type products (thermoplastic sheets, foams, padding, linings, protective layer fabrics, transfer papers, closures) that fill helmet and orthotic tree positions — these are not raw materials but configurable components selected by the CPO during device configuration
NOT READY AC-CAT-112 [CO] Standard specification fields for helmet padding include pre-perforated and perforatable boolean tags. Pre-perforated products are manufactured with perforations; perforatable products can be perforated during fabrication
NOT READY AC-CAT-113 [CO] Standard specification fields for helmet protective layer fabrics include fabric type (e.g., microfibre, 3D breathable) and material (for allergy checking — the protective layer is in direct skin contact)
Free-form entry edge cases
NOT READY AC-CAT-090 [CPO] If a free-form entry matches a product that already exists in the shared catalogue (same manufacturer and model name), the system suggests the existing product to the org admin during review
Pentla Acceptance Criteria Dashboard | Source: pentla-specs | npm run dashboard to regenerate