Have questions?  info@icarol.com

Follow Us! iCarol software twitter iCarol software Facebook iCarol software YouTube iCarol software LinkedIn     |    FREE TRIAL     |     SIGN IN

Considerations for sharing resources in iCarol

sharing resources

If you are planning to share resource databases with partners on a one-time or ongoing basis, there are a number of factors to consider and discuss with your partners to yield the best possible results. This is because each database has likely been built with different assumptions, policies and approaches that would make searching in a shared database inconvenient, inconsistent or even problematic. What follows is intended to help identify problematic areas and stimulate conversations on how to address them amongst the partners and with the iCarol team. If you have alternative ideas or approaches, by all means please let us know.

There are many possible reasons for variations in database approaches, some of which include:

· Urban or rural constituents – Urban areas tend to have service providers that can be complex, with many sites and programs, while rural areas may have smaller and more simple entities. Hence rural databases may find more “collapsed” resources….in the simplest form, an Agency record could contain all the information about the entity, with no Programs or Sites at all. Urban areas may need more granular coverage areas (e.g. neighborhoods), while in rural areas some zip codes can span dozens of square miles and are not granular enough.

  • · Quantity of resources in database – The more resources in a database, the more important it is to be able to distinguish them from each other so relevant resources are found in searches. This means you likely will activate lower levels of the taxonomy to get more precision in your coding.
  • · Geographically large service area – If your phone workers are answering calls far from where they work and live, they will likely be less familiar with those distant areas. Likewise, people using your database from afar might not be familiar with colloquial names of geographic areas or services. 
  • · Limited capabilities in a previously used I&R software system – Some older versions don’t support Site entities, so all location information is at the Program or Agency level. Also in such software, when there is one Program offered at an Agency, much of the information will be duplicated in both records, which can be problematic when it comes time to update the records.
  • · Tenure of your phone workers – If you have a high turnover rate for phone workers, it may be one reason to keep your resource database “simple” so that new hires can be trained more quickly.
  • · And more… – There are surely other reasons to add to this list as well. Hence when planning the sharing of resources, we recommend discussion and, as much as possible, agreement amongst the partners in the following areas. Thankfully, in many areas the import process itself can be engineered to transform databases to comply as much as possible with the wishes of the collaborative.

    Through this discussion, you have the choice of either consolidating all databases into one in iCarol, or for each call center to retains its own database in iCarol, and share it elegantly with all partners from within iCarol on a read-only basis.

    Agency / Program / Site hierarchy – At what level of the resource database should service delivery information reside? Where should location information reside?

    There are actually four different candidates: Agency, Program, Site and ProgramAtSite. (In the AIRS community, these entities can go by different names.) Clearly you wouldn’t put service delivery information into in the Site record, so, much of the service delivery information should reside in Program records. And yet there can be variations on service delivery information from Site to Site – for example, coverage area and contact information.

    Recommendation: During the import process, we can put as much service delivery information in the Program record as possible, and only that information which varies from a Program’s offering at different Sites should be placed in the ProgramAtSite  record. For those databases that might have Agency records with no Program record, we’ll create one for it to be consistent with other databases. And all location information will go into Site records. We can configure iCarol so that it’s smart enough to look at the correct level of hierarchy for searching and viewing records.

    Taxonomy customization

  • For reasons mentioned above, it is likely that the partners have all customized the taxonomy with different codes activated and de-activated. A long term effort could be made by the partners to establish one common taxonomy customization. In the meantime, however, we have a setting in iCarol so that when you are searching in a taxonomy term, it can also “look down” into lower levels of the taxonomy and include resources assigned at those lower levels, too, in the search results. Similarly, we can enable “look up” capabilities too, in case a worker is looking a more granular a level. These settings can be configured differently for each call center.

    Colloquially-named regions

  • In some I&R software systems, agencies can define custom regions upon which their coverage areas are based (e.g. “Northern Virginia” or “South-central Baton Rouge”). Unfortunately those regions are not often composed of “official” entities like zip codes, cities or counties, making it difficult for searchers from other areas to know the territory the custom region actually covers. So during the import process, if we encounter such custom regions, we will work with the database owners to translate them into official entities.

    Lack of coverage areas In some databases, coverage areas are not used at all and I&R specialist may simply do their geographic filtering by the city or county in which the resources are physically located. Or they may do no geographic filtering because their service area is small, or perhaps most entities in their database all cover nearly all of their call center’s overall service area.

  • In these cases, we can have iCarol automatically create default coverage areas upon importation (based on the record’s home city or county) so that people using the resource database who are used to being able to use a coverage area in their own database, can still do so in the ones they are “visiting”.


  • Many times, neighboring I&R centers will have the some of the same entities in their respective resource databases, especially if the service providers serve both areas. It would be highly unlikely for those resource records in both databases to match exactly. So during the import process we can work with you to develop your criteria for identifying duplicates and either de-duplicating them automatically, flagging them for you to deal with manually, or a combination of both. In some cases however, 2-1- 1 centers may want to keep records in their own “local” database for easy access, and we’ll defer to your preferences for those cases.

    State-wide resources

  • The opportunity to have these statewide / provincewide / nationwide resources managed once, in one database, rather than many separate times in each database, presents excellent time-saving and data consistency benefits. Who should maintain them and in which database(s) should they reside? Technically we can pursue whatever course you would like, ranging from continuing to keep them in each center’s own resource database, to creating a separate “statewide resources” database into which they will reside. We can then make them automatically included whenever you’re searching in any of the local databases, and also editable by any authorized user from within their own iCarol system. If we choose this latter approach, we’d need your assistance in identifying the statewide resources (although they could be easy to find if they have a statewide coverage area already).

    Style guide

  • Some 2-1-1 centers may have developed style guides on terminology and appearance of fields in their resource database. As a small example, should phone numbers be formatted like 415-555-1212 or (415) 555-1212 ? Hours of operation – should they be in 12-hour or 24 hour format? And so on. If you have (or want to develop) a style guide and have that applied during the import process, we’d be happy to do so for you.

    Problems/Needs and Unmet Needs

  • Across our client base, we’ve encountered quite a range of how Needs are identified and collected. This ranges from centers using the 2-1-1 Taxonomy itself to express needs, to their own custom (and sometimes hierarchical) list, as well as a combination of both (to cover Needs not in the taxonomy, like a business or administrative type of call).
  • We are increasingly seeing centers standardize on using the 2-1-1 Taxonomy as the primary method for need identification, and only sparingly have additional custom needs for those small non-Taxonomy cases. The approach seems to work well, so we recommend it to you. In addition, using the Taxonomy allows you to roll-up your aggregate needs for the annual AIRS “Big Count”. Regardless of the approach you choose to take, consistency in this area across the state would result in much better aggregate reporting.
  • The list of reasons why a need might be unmet can also be customized, and we do see variation amongst our client base. We recommend trying to standardize this list too, so you can have consistent reporting on reasons for unmet needs.

    Other Data Collection elements

  • If you would like even more robust statewide aggregate reporting, we also recommend developing a common data collection schema for calls. Demographic fields like caller age, gender, ethnicity.
  • Our best example of such a harmonized schema is the result of a multi-month project conducted by the Distress Centres of Ontario, where extensive time was taken to consider a wide range of data collection fields. We have permission to share that with clients, and have other examples as well.
  • In addition, we’d be happy to share what other clients in our system are using, as well as work with you to harmonize what is collected across your centers into your own statewide schema. Even if you do develop a common schema, note that each call center is free to go beyond it by customizing their own iCarol system to collect additional information they need.
  • Also, we have ways of “mapping” fields collected in different systems together for data aggregation purposes, so that the fields don’t have to be exactly the same but can still be combined for aggregate reporting.


  • While there may be additional areas to consider, we hope this gives you a good start in thinking about the how to approach the importation of resources for your project. We at iCarol are your collaborative partner in this process and want to work with you to achieve the best possible outcome.

    Last updated September 29, 2011 Neil McKechnie, Director of Services neil@iCarol.com

  • © 2023 iCarol, a Division of N. Harris Computer Corporation. All Rights Reserved.

    iCarol helpline software   iCarol helpline software   iCarol helpline software   iCarol helpline software