ServiceSite Data Structure vs. Agency-Program Structure
The ServiceSite data structure is the design of the database that supports the I&R software. This structure defines the relationship between the agency (the service provider's parent location) and it's service delivery locations (Sites) as well as creating the relationship between the services and programs offered by the agency and how these services are "linked" to the appropriate site. At a minimum the ServiceSite data structure requires four levels of information: Agency, Site, Service Group (Program), and ServiceSite. Certain variations of the ServiceSite structure may involve up to six levels.
The Agency-Program data structure is also a database design used in other I&R software. This structure originated from I&R software development projects that would automate a service provider Rolodex.
This structure offers two levels of information, an Agency (Parent Location) record and a Program record (a combination of the service delivery location information and the services offered at that location).
How do the two structures compare?
Agency-Program Structure
From a simplistic viewpoint, the Agency-Program structure appears that it will meet the needs of a resource database. When entering a single location service provider with one or two "Programs", this is true. In fact it is just as easy in both structures.
But this is where the simplicity ends. When a complex service provider must be entered into a database, the Agency-Program structure gets overly complicated and redundant. An example will highlight the issue.
Suppose we have an agency that has four separate locations and each location offers four different types of service. When the data is entered into the Agency-Program structure the end result is seventeen records: One Agency record and sixteen "Program" records.
Each "Program" record contains a combination of location information (name, address, and phone numbers at minimum) and information about one of the types of service (Taxonomy Terms, Keywords, Eligibility, Fees Hours, Application Process, etc.). The location information is duplicated four times and each type of service is duplicated four times. (4 locations x 4 types of service = 16)
If any of the location information changes, it must be corrected in at least four "Program" records. If the information changes for one of the services (Programs), the data must be changed in four "Program" records.
Imagine what this would be like in the "Real World" when you have a service provider that administers 100 service locations (one in each county) and each location offers 3 to 5 different types of service (Programs). That's somewhere between 300 and 500 "Program" records to maintain.
ServiceSite Structure
Using the same example, one Agency, four locations and four types of service, a ServiceSite structure will create nine records. One Agency record, four Site records and four Service Group records. If any of the location (site) information changes, it is updated in one record. If a Service Group's information changes, it is updated in one record.
Using the Agency with 100 service locations and 3 to 5 types of service example, at maximum the ServiceSite structure will create 106 records (one Agency record, 100 Site records and 5 Service Group records)
Bottom Line - the ServiceSite structure requires much less resource maintenance.
Service Searching Accuracy
The ServiceSite structure offers exponentially better searching and display properties. While this topic is more geared for the "Techie-Types", it highlights a critical difference in the day-to-day performance of the two structures.
Starting with the Agency-Program structure, you may remember that this is a two level structure. While the Agency record in both structures offer little value to the caller who needs assistance, the "Program" record in the Agency-Program structure is the workhorse. This is were the vital service location and service information is stored.
In a single "Program" record there are three components:
-
Service Delivery Location Info (name, address, phones and more)
-
Service Information (Hours, fees, how to apply, who is eligible etc.)
-
Search Terms used to locate the "Program" (Taxonomy terms or Keywords)
All search criteria information such as Area Served, special filters, age and gender restrictions are linked to the "Program".
Suppose the "Program" contains three services (as described by the selected Taxonomy or Keyword terms) and each service has a distinct service area? Service 1 serves the entire county, service 2 serves only one city, and service 3 serves only three out of the six ZIP Codes in the city. The Area Served component can only be linked to the "Program" record, not to the individual services in the "Program" record. This is where the problem with accuracy starts.
Which service area should be linked to the "Program"?
The county, the city, the ZIP Codes. How about all three? No matter which service area is selected, at minimum two of the services will be wrong. The service searches in your Call Center and on your public access Web site will be wrong. This will not be a good reflection on your organization.
What is the work-around for software using the Agency-Program structure?Only one, create individual "Program" records for the individual search terms. This will work but remember the duplication problem that you are already facing by using the Agency-Program structure in the first place. Multiply that by 100 and you will get an idea of what you are facing in order to maintain an accurately searched Agency-Program database.
Suppose one of the service in the "Program" is temporarily inactive, what's the option?
Inactive the whole "Program" or leave it. Probably leave it and write a note and hope the Call Specialist sees it. Not very efficient.
There is a better way to search accurately
You guessed it, the ServiceSite structure. The Service Group record in the ServiceSite structure contains two pieces of information:
-
Service Information (Hours, fees, how to apply, who is eligible etc.)
-
Search Terms (Taxonomy terms or Keywords) used to locate the Service Group and the associated Site record.
Each service delivery location (Site) is linked directly to one or more of the services in the Service Group (depending on what services are offered at the particular Site). Each "Link" between one of the services in a Service Group and one of the Sites is called a "ServiceSite" record which means "one service at one site".
Each unique ServiceSite record contains the Area Served, age and gender, special filter, notes and status information for that one service at that one Site. Therefore when services offered by a particular service location (Site) each have unique criteria such as service area restrictions, it's not problem because each ServiceSite record contains it's own data, independent of any other service offered at the Site. This is another reason the ServiceSite structure is the only way to go.
Now if you are a real gear-head, the next logical question would be, "Does this mean that settings have to be made for every single service in my database? That would be a lot of work". The easy answer is "Yes". All ServiceSite records will contain their own setting. This is where the software plays it's part. Any good I&R software will provider Global Update features for those records that share the same or similar information. In fact, well over 50% of the sites that offer services will share the same ServiceSite settings so the Global Update utilities will be very handy.
Summary:
From the simple standpoint of day-to-day resource data maintenance, the ServiceSite structure requires a fraction of the time and effort to maintain a comprehensive resource database as compared to the Agency-Program structure.
The ServiceSite structure also provides better service searching accuracy than any other I&R database structure.
But this is not where the benefits end. The multi-level structure also provides precise data extracts and more concise and smaller printed directories.
The Service Site data structure is the only database format that can fully support advanced I&R functionality and is endorsed by sophisticated I&R organizations as well as knowledgeable I&R software developers. The ServiceSite structure is also the structure selected for the AIRS XML Data Transfer standard.
Why would a software vendor use anything other than the ServiceSite data structure for their database design?
In all fairness to I&R software developers, programming a software system to utilize a ServiceSite data structure is difficult and complicated. While the benefits of this structure are significant for the end-user. The result is an easier to use and maintain application. The vendor must have the expertise and be willing to invest significantly more time and effort in order to take full advantage of this structure.
How can you tell if a vendor is using a the ServiceSite data structure for their database design?
If the I&R software is an RTM Designs product, the software is using the ServiceSite data structure.
All other I&R systems use some variation of the Agency-Program structure.
The Database structure is the foundation of any information data driven software system. Selecting software with the correct structure greatly enhances the users capabilities and ensures unsurpassed functionality, now and into the future.
