E.10:12.1 - Healthcare (operating-room planning and work)

Messy: “The surgical process is scheduled at 08:00; the SOP approves the incision and the service documents recovery.”

Repair, taking service here to mean the ward team: “Schedule Incision_221 in OR_Case_221_WorkPlan for 08:00, using IncisionMethod. SOP_OR_v4 states the incision-readiness constraint. QAApprovalSystem performs the approval; record its speech-act content. Separately recover the applicable A.21 profile and required check results. Its GateDecisionResult states whether and under which conditions the planned run may proceed. The ward team records Patient_221’s recovery in RecoveryRecord_221.”

Formal plan membership. OR_Case_221_WorkPlan is used as U.WorkPlan only after A.15.2 membership is established: its already identified present EntityOfConcern is Patient_221, its horizon is the bounded surgical-planning interval, and Incision_221, a PlanItem substantively coordinates the intended surgeon classification and assignment conditions, operating-room resource reservation, planned start of 08:00, IncisionMethod, the U.Method, and the incision-readiness target. It cites IncisionMethodDescription, a separately identified claim-bearing episteme. That episteme is U.MethodDescription only because the method is its exact EntityOfConcern and its claims substantively describe how the method is carried out. Any edition identity needed by the plan is selected through a separate U.EpistemeRef whose subject pattern supplies its rule; carrier version remains separate.

Actual approval Work. For ApprovalSpeechActWork-221, recover QAApprovalSystem as exact actual performer through A.13 and let A.15.1 independently admit the dated Work. Add F.6 only when this account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Add ApproverSystemRole only when that classification matters.

Separate source claims. If the source also specifies a monitoring promise or an access method, recover those additional claims separately: PostOpMonitoringPromiseContent states the promised monitoring and its vitals acceptance envelope. WardAccessMethod : U.Method names the exact access method; WardProtocol is U.MethodDescription only if it is a separately identified claim-bearing episteme about that method and passes A.3.2, while its publication form and carrier remain separate. These are additional claims, not replacements for recording recovery.