Domain Constraints

In addition to being defined first by domain type and then by the individual domains of a given type, users should be aware of the following constraints as they define and use domains.

1. Domains serve either as a scheduling or administrative entity.
   • The Multi-site version of the scheduler has only one administrative (nonscheduling) domain. Enterprise versions have no limitation in regard to the kinds or number of administrative domains that can be created. Both versions of the product limit the number of scheduling domains according to the sales agreement.
   • Administrative domains are used to organize supporting data and to provide some defaults, such as the hours of operation. Appointments cannot be scheduled in administrative domains. In addition, administrative domains are reporting units and can be used to compare information across the organization.
2. Administrative domains are sometimes referred to as the "parent" of the subordinate domains or "children." They own-administratively-the scheduling domains assigned to them.
   • The organizational hierarchy is something that the program administrators set up. This hierarchy has significant  importance in regard to who has access to information.
3. Users must be assigned (a) to at least one domain and (b) to a security profile for each domain to which they have been assigned.
   • Users cannot schedule appointments until they have been assigned to a domain (in addition to being given a user name and password) and a security profile for that domain.
   • By virtue of the parent-child relationship of the domains then, a user with the appropriate security who is assigned to Rehab Medicine in Hospital X, for example, could schedule in and run reports on all the domains that it oversees. A user assigned only to the PT Department, however, will have reporting and scheduling rights only for that domain.
4. Resources must be assigned to a domain before they can be scheduled in that domain. For example, a resource who works with both PT and OT patients must first be assigned to both the PT and OT domains before he or she can be scheduled in those domains.
• Resources cannot be assigned to a nonscheduling domain.
• Resources cannot be created until at least one domain type and one scheduling domain exit. Use one of the default domain types that ship with the program or create your own. You will have to designate a scheduling domain.
5. Patient cases must be assigned to each domain in which the case needs to be scheduled. That is, patients must be assigned to each domain in which they will receive treatment.
   • Patient records cannot be saved until at least one domain exists. As a shortcut, users can choose an administrative domain. This will have the effect of assigning the case to all of the scheduling domains that are subordinates of the administrative domain. If the domain relation changes, however  (for example, a new scheduling domain is added to the administrative domain), users will be required to assign that case to the new domain (where appropriate). Otherwise, simply check the individual scheduling domains appropriate for the patient’s care.

These constraints outline the global conditions that should be considered as administrators define domains and as users work in and with the scheduler. If a user profile does not provide access to specific parts of the program, users should consult with the program administrator to resolve any issues.