Listing 1 describes the general structure of the solver. Hospital data is read into the relevant sets (Lines 5-9), and surgical procedures (Operations) are separated into two sets (Lines 11-16): (i) procedure names ("Names"), a set of symbolic terms that cannot be parsed by the arithmetic constraint solver and (ii) procedure costs ("Costs"), a set of integer terms. We formulate the solver as a resource allocation problem. We first specify arithmetic constraints. The solver assigns the number of supported procedures using the integer costs specified for each procedure type: the length of the solution set ("OP") is equal to the length of procedures (Lines 18-19), the integer range of "OP" is between zero (no procedures supported) and the maximum number of procedures for the procedure with the least cost (Line 20), and the accumulated cost of all supported procedures does not exceed the total cost (Line 21). Note that the #=< symbol denotes ≤. Then, we specify high-level constraints with the "constraints/3" routine (Line 23). The main routine "solve/2" (Line 3) finds all possible instantiations of surgical procedures using the built-in "labeling/1" routine (Line 25) and the interval arithmetic constraint solver library (Line 1).

Listing 2 describes how high-level constraints are specified in the form of traditional Prolog rules. The constraints for each type of procedure are represented with the "operable/3" routine (Lines 1-5). The number of supported surgical procedures is greater than zero (Line 8) if there is a physician capable of performing that procedure (Lines 9-10). Otherwise, the number of supported surgical procedures is zero (Lines 12-14). Note that the \+ symbol denotes negation as failure.

Procedures can be further constrained using the "perform/2" routine. The first rule (Lines 17-21) describes regular practice. A physician must be authenticated in Hospital A (Line 18), must be an expert in performing the specific procedure (Line 19), and there must be a detached authorization meaning that the physician has obtained consent from the patient (Lines 20-21). A specification having this rule corresponds to the Suboptimal specification, since it provides liveness in regular practice, and preserves safety via authentication and consent. This rule can be relaxed with the "perform_relaxed/2" routine to provide more flexibility to the physicians in emergencies (Lines 24-26). This second rule (Lines 28-31) relaxes all three constraints of the first one. Authentication is extended to cover other hospitals (notice the free variable Hos in Line 29 instead of the ground term hosA). The need for obtaining consent is removed. However, an additional dialectical commitment is required from the physicians to establish their expertise (Lines 30-31). A specification having this rule corresponds to the Enhanced specification since liveness is increased by relaxing some safety constraints.

Figure 1 shows the output of ECLiPSe for the query "solve(Procedures, 50)" regarding the Enhanced specification in regular practice mode.