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.
Previous
Start Over
Next
|
