i) Determining the patient's status (enrolled, paid-up, etc.)

ii) Determining whether the patient is excluded from coverage

iii) Verifying that the claim has not already been processed

iv) Rejecting the claim if certain criteria are met, providing an explanation

v) Determining whether the doctor is an authorized provider of care

vi) Determining whether the procedure is authorized for the doctor

vii) Calculating the reimbursement based upon the doctor's authorization and updating the database with this information.

i) The requirement of checking the patient's status cannot be fulfilled without knowing the possible values of the "Membership Status" field in the Patient File table.

ii) Checking whether a patient is excluded from coverage is not possible without knowing how the "Exclusions" field is structured; it could be a delineated list of excluded procedure numbers, or it could be something entirely different.

iii) Checking whether a claim has previously been processed is not possible without more information on how the claim number is generated. If the claim number is a unique ID generated by the database, checking for duplicate claims is impossible because there is no "Date" record in the Claim File. If a third party creates the claim number, one could check whether or not that number already existed in the database.

iv) The requirement of rejecting the claim with an appropriate explanation is ambiguous because the functional specification does not state how rejection should be flagged in the database (most likely by setting "Processing Status" in the Claim File database to some predetermined flag), nor does the specification explain how the explanation should be generated or stored.

v) Determining whether the doctor is an authorized provider of care is impossible without first knowing the list of values for the "Overall Authorization" field in the Doctor File database.

vi) As in item ii, whether the procedure is authorized for a doctor cannot be determined without more detail on how this information is stored in the database.

vii) Calculating the reimbursement is an ambiguous requirement mostly because of the inconsistent and unclear wording used in the specifications. "Pay the lesser of the submitted amount or the standard amount for the procedure" and "Pay 67% of the lesser of the submitted amount and the standard amount for the procedure" appear to be requesting different percentages of the same thing, but the change in wording creates confusion. Finally, "Pay the submitted amount and TBD% of the standard amount for the procedure, whichever is less" borders on being grammatically nonsensical, and is difficult for the programmer to interpret. The "TBD" adds to the ambiguity because the programmer is not told when or how he will receive this information. Perhaps the correct percent was simply omitted from the functional specification by accident.

i) The developer is asked to reject the claim with an appropriate explanation, but the database structure contains no field to store any comment.

ii) The specifications make it sound as though the override is a Boolean that is set on or off. However, the field name "Override Code" in the Claim File database suggests that it is not a simple True/False value.

iii) The Doctor File database appears not to have any record of which specific procedures the doctor is excluded from performing, only an "overall" status that presumably refers to whether or not the doctor is an authorized provider. Without being able to determine which procedures the doctor is authorized to perform, it is not possible to correctly calculate the payment amount.

iv) The specifications allude to the fact that the Procedure File contains "the maximum" amount that he health plan is willing to pay. However, the actual database does not contain this information, although it does not appear to be necessary for the application to function.

v) The current method of storing exclusions as a field in the Patient File (and presumably in the Doctor File) is highly unorthodox, and contrary to commonly accepted standards for database structure. The database should ideally contain two tables that are not included: "Authorized Patient Procedures" and "Authorized

Doctor Procedures." These tables would contain two values: Patient/Doctor ID and Procedure ID. These two values would create a unique composite key, which could be used to quickly determine if a procedure is authorized.

vi) The current table structure creates an environment in which patients and doctors are automatically authorized for procedures that they are not explicitly excluded from. Thus if a new procedure was added to the Procedure File, payment would be made as if every member of the health plan was authorized to receive that procedure. This seems contrary to sound business sense, and would be fixed with the dual lookup table system described in item v.

vii) One minor mistake is that, due to the layout of the specifications, it is impossible for the developer to tell whether the Doctor File database contains one field called "Overall Authorization Status" or one field named "Overall Authorization" and another one named "Status."