Domains Overview

The developers of the program have long recognized that scheduling in a multidisciplinary environment such as a hospital or a therapy group requires more flexibility than a straightforward resource-time allotment. Specifically, the needs of everyone who uses the scheduler do not always match: Hours of operation can vary; the standard length of an appointment can vary; resources can work in different locations or departments that do not share the same workdays, or different domains may not share the same supporting data. One solution that we have developed to handle such scenarios is a flexible, comprehensive domain system.

Domains form the administrative and scheduling units of your organization. They provide the structure or framework for

Licensing
Security
User creation
Data maintenance
Scheduling

The hours of operation, the workdays, alert preferences, and supporting data, etc. are all configured in a manner that best fits the business and scheduling workflow requirements of each domain. Users are assigned to domains before they can schedule or report on schedules. Patients and resources must be assigned to domains before they can be scheduled. In short, domains are integral to how information is stored, used, and extracted from the scheduler.

A domain is a collective unit within a larger structure whose members have the same scheduling requirements. A unit can be as simple as a single location in a multilocation organization. It can also be a department within an organization. Domains are not, however, restricted to physical locations. For example, a hypothetical “affiliated therapy” organization comprised of multiple locations could create a domain for each location but could also create a Physical Therapy domain that administers all the various PT locations, an Occupational Therapy domain that administers all of the OT locations, a Diagnostic domain for all diagnostic services, etc.

Types of Domains

Domains can be one of two types:

Administrative domains are designed purely to help organize and make data consistent across subordinate domains. They are reporting domains.
Scheduling domains are where resources and patients are actually scheduled. You can report on scheduling domains, but the configuration settings and data assigned to these apply only to the specified domain.

Understanding Domains Through Example

Each of these is represented in the following example of a domain structure for the hypothetical rehabilitation network ACME Affiliated Rehabilitation Network.

Think of the structure of domains as a “top-down hierarchy” of associations. Higher level domains “own” or have administrative rights to the lower level domains that are associated with them. In most instances, this gives users who are assigned to a higher level domain rights to all the subordinate domains. A user assigned to the Tempe domain, for example, can administer or report on all the departments belonging to the Tempe office: PT, OT, and SLP. Additionally, this hierarchy creates a “trickle-down” effect in that data that is assigned to a higher level domain is automatically associated with its subordinate domains. This includes supporting files such as diagnoses and procedures as well as patients.

The preceding table illustrates an network of services across the Phoenix metropolitan area that include offices in

Tempe

Scottsdale

Glendale

The top-level administrative domain in our example is the network itself: ACME Affiliated Rehabilitation, which is represented in blue. This domain administers all of the other domains in the network. Additional administrative domains are represented in bold, black text. The secondary administrative domains are of two types that include (a) physical locations and (b) the services provided at the locations. For example, the Tempe domain (location) offers the following services represented by the respective department designations:

Physical Therapy (PT)

Occupational Therapy (OT)

Speech Therapy (SLP)

These “departments” are the actual scheduling domains, and they are represented in red text.

The example provided illustrates three domain tiers. (a) The organization ACME Affiliated Rehabilitation is the topmost tier. This is an administrative domain by definition. The locations and the services provided at the locations represent the second-level administrative tier. And the individual “departments” or “disciplines” in which patients and resources are actually scheduled represent the third-level—scheduling—tier. As you work with domains, keep in mind that

Resources can be assigned only to a scheduling domain and must be assigned to each domain in which they require scheduling.
Patients are assigned to domains through their case. They can be assigned to any domain in the organization, and if the case is assigned to an administrative domain, then the patient will be available to be scheduled in any scheduling domain that belongs, or is subordinate, to the administrative domain.
Users must also be assigned to the domains in which they work—either a scheduling, administrative, or some combination.

Each user-domain combination can have its own security profile assignment. That is, a user could have scheduling rights in one domain, but only be able to view information or run reports in another.
Users must be assigned to every domain to which a patient case has been assigned in order to edit the case. However, if the case belongs to at least one of the domains to which the user has been assigned, then the user can schedule it in the corresponding domain.

In contrast to the Tempe domain is the Physical Therapy domain, which represents a service provided at each of the physical locations. An example of why you may want to create a service domain such as Physical Therapy is that you can aggregate data for reporting and business workflow issues, promote consistency between the offices in regard to data maintenance, etc.

Note that Multi-site installations are restricted to two tiers only: They have one administrative domain, and all subsequent domains must be scheduling domains by default. Because of this, the organizational hierarchy is created automatically once the administrative domain is established. A simple example is illustrated in the following table.

Prior to implementing the program in their organization, administrators should take the time to plan and organize the domain types and domains before they begin structuring Appointments to fit their need. By outlining the desired end result on paper prior to entering the domain structure in Appointments, you will expose any issues you may not have thought of and simplify the data entry process.