Accessing roles:

All the fields in the upper region are mandatory when editable. Then details data grids, just below, are about :

• Queued events: pending and unscheduled events; Double click mapped data dialog: Waiting list dialog.
• Appointments: scheduled events; Double click mapped data dialog: Organizer. A flag allows a 'future only' insight.
• Clinical cards:
  • Double click mapped data dialog: if selected row, Clinical card else Descriptor dialog.
  • The Descriptors button opens the Descriptor dialog
  • The Unified button merges the details of all the listed Clinical cards and opens them as a single details data dialog

The Related invoices (view) button opens in read-only mode the Customer invoices dialog populated with the data of all the customers related to the patient

Accessing roles:

The panel allows the specification of many customers as related to the current patient. Each record created is dedicated to a related customer.

The customer must be selected by the use of the Browse button that opens the Person searcher. Then a relationship (descriptive) must be specified or the checkbox Is the patient must be checked for asserting that Customer data and Patient data refer to the same physical person (the system alerts if names do not match but allows the mismatching)

The Customer details button opens, in read-only mode, the details panel of the customer data, like that one that composes the Customer dialog

The Invoices and Estimates buttons give an insight of these inherent details for the customer just as those ones contained in the Customer dialog

Accessing roles:

The panel allows the creation and the collection of more records related to the current patient. The fields have all obvious meaning a part from Practitioners: The doctor that has access to this panel can be listed in the drop-down list if he/she has been inserted in the Practitioners dialog. If this is the scenario typically the doctor operates as by self and his account has been equipped with the 'Practitioners' role but this is not needed for the access to this panel.

Accessing roles:

All the fields, when editable, are mandatory except the last two phone numbers and the Note field. In the lower part there are two details data grids:

• Insurances: the insurance coverage as all the possible insurances registered with the customer. Double click mapped data dialog : Insurances dialog.
• Patients: the patients which the customer is responsible for, about payments. Double click mapped data dialog : Patients dialog.

The Invoices and Estimates buttons become enabled when a patient row is selected and open the respective details dialog, that is, respectively, the Customer invoices dialog and the Customer estimates dialog

• Main data

  Essentially the mapping between symbol and description is defined here.

  The Type option is only for helping the look-up that provides even in the criteria fields the same attribute available. 'Any' means that the treatment is classified both for general context and for specific tooth context.

  Accessing roles:

  Role	Permissions
  Administrators	all
  Doctors	read-write
  Practitioners	read
  Administrative personnel	read

• Price

  Allows the definition of prices. The Default one propagates its value on intervention definition (see Interventions dialog). The Maximum is not processed by the system but only collected for records

  Accessing roles:

  Role	Permissions
  Administrative personnel	read-write

Accessing roles:

The region headed with the label Selection of the context allows, just as said, the identification of the target entity, that is the tooth or the entire mouth, either for an overall insight of the related data or for the settlement of it as central main datum in respect of which opening the details dialog mapped to the details grids, in order to perform the editing, indeed.

The horizontal bar that separates the upper and the lower arcade represent the entire mouth and behave as analogical selector together with the teeth of the arcades (upper and lower - decidual and/or normal)

The selection of the context, indeed, may be performed by means of the analogical entity or by selecting a row of the grid.

Accessing roles:

It is apparent that only Doctors are responsible of the maintenance of the card in term of creation, deletion and editing of the main properties (dates and notes). By comparing the permissions with the ones of the Clinical card dialog results that an operator in order to have full control on the clinical cards data must own both Doctors and Practitioners roles.

Number is an auto-increment integer that enumerates the cards of the patient

Accessing roles:

Treatment and Diagnosis time fields are mandatory. The first one must be specified by means of the Browse button that leads to the Treatments data dialog opened as selector.

Exeution time, when entered, tells the system that the intervention is to be enumerated in the executed interventions.

Accessing roles:

The main data are presented as attributes of the company

Every company may have one or more reimbursement plans built as percentage of the price of each treatment registered by the application

These plans are listed, by name, in the Reimbursement plans grid. Double click mapped data dialog : Reimbursement plans dialog.

Accessing roles:

The one only data panel collects the most significant quantities that define an insurance coverage

The coverage type is summarize in a domain of three values:

• Deductible / Maximum: the coverage is complete but is actual when the amount, spent in the benefit period, is between the Deductible amount and the Maximum amount
• Coinsurance provision: the coverage is based on a percentage of what is spent in the benefit period
• Reimbursement plan: the coverage is based on a percentage reimbursed specific to each treatment.

The Type drop-down list helps to locate the suited quantities but lets the user, also, to enter all the values, in fact it provides the 'custom' value. The system processes these data only in the compute of an estimate and does not take in account the benefit period that lasts a simple collected datum for records.

The algorithm by which the quantities are elaborated, is documented in the Customer's estimates dialog.

Accessing roles:

The dialog allows the composition of an invoice picking interventions up from the grid of the Available items; double clicking on this grid the item of the row is pushed into the Items grid, that is ...items of the invoice.

Note: For the invoicing it was chosen to make available also interventions where the execution time is not specified (maybe was not for some reason); it is up to the administrative user to recognize the actual item to be invoiced: the system presents, as available, all those ones related to the patient (mentioned in the heading of the invoice) and not yet invoiced (not yet present in other invoices generated for works for the patient). As an help the Intervention details button is available: when the dialog is in editing mode and before any exchange occurred between the two grid, the button provides details of the intervention selected in the Available items grid.

An invoice can manage only works for only one patient.

The lack of the patient value means that the customer is the patient too.

The main differences are that:

• there is no Number field
• 'Amount' becomes Cost by respecting the point of view of the customer that is waiting for the estimate computation
• A couple of fields appear: Insurance and Already spent. The former is one of the insurances of the customer, identified by its friendly name (see the Insurances dialog) and the latter is initialized by the field having the same name in the insurance record but can be customized / actualized and with its new value it is stored in the estimate document. The 'Insurances' field is modifiable until an exchange of items occurs between the two grid
• In the 'Available items' grid the presence of the 'Reibursement (%)' column that indicates, for the selected insurance, the reimbursed percentage of the item price based on the possible existing reimbursement plan
• Pushing items in the estimate does not avoid that the same items were pushed in other estimates (it makes sense building more estimates for a scenario and it is not the same for an invoice).
• There is no Render button

It is the application organizer.

Accessing roles:

By means of a calendar instance it allows navigation along the time and allows to set up the appointments either by double clicking a row of the grid on the right, so that the Appointment dialog opens, or by dragging and dropping a grid row from the Interventions grid of the Clininical card Dialog or from the Waiting list dialog

In the first case a simple appointment is created, in the second case the appointment is transferred as is, a part from the acquisition of the coordinates.

Let's say 'time slot' the interval time five minutes long in which the whole working day is divided.

Accessing roles:

This is a single record data dialog that allows to set up the definition of an appointment.

It is opened either from the Organizer or the Waiting list. In the first case the fields at the top are populated by the coordinates of the first time slot, mandatorily engaged by the appointment definition; in the second case they are empty.

The selection of the patient is mandatory and must be accomplished by the next Browse button.

The Duration field is mandatory too (expressed in minutes) because it is used by the system for the management of the time coverage.

The Details button makes the opening of Patient details dialog.

This is the place where an appointment is defined as built by a single intervention or more interventions (in which case it is said 'macro').

The Macro check box asserts that truth.

The dialog has special behavior in respect of data access when the switching occurs between the two inherent states:

• regardless the versus of the switch the system alerts the user that, in order to continue, data modified during the editing session will be saved (making useless the 'cancel' command)
• by switching the 'macro' attribute on, if the intervention was specified then the interventions grid, contextually appearing, is initialized with the intervention
• by switching the 'macro' attribute off, if the interventions exist then the following options occur:
  • if the interventions grid contains one only item then this one is used to populate the definition of the intervention in the simple asset
  • if the interventions grid contains more items the user is alerted that all of them will be deleted

In the macro state the changes to the interventions grid performed by the Add and Delete buttons are immediately effective and the editing session of the dialog continues independently. The same is for modifications to the grid derived by dragging and dropping a row from the interventions grid of the Clinical card dialog

Accessing roles:

This data dialog is made only by a grid the row of which can be dragged up and down to change the queuing order of them, order marked by the first column.

Adding rows is possible only by dragging and dropping interventions from the interventions grid of the Clinical card dialog or appointments from the Organizer

In the first case a simple 'undefined' appointment is created, in the second case the appointment is transferred as is, a part from the leakage of the coordinates.

A row can be edited double clicking it: the Appointment dialog opens. Then the appointment can be also deleted.

The composition of the grid is similar to that one of the grid on the right in the Organizer.

Provides the core definition of the armchairs managed by the system.

Accessing roles: