Healthy DC – Go Local: It Takes a Village

Abstract

Since the acceptance of the Healthy DC – Go Local proposal in November 2007, members of the District of Columbia Area Health Sciences Libraries group supported the project by offering their time to select health care services, perform data entry, review records, and promote the database to their organizations. Although the amount of work required to sustain the database became more than the Go Local team was able to handle, the collaboration, dedication, and persistence of project managers, volunteers, and part-time staff members was what made the project a truly collaborative one and an ultimately successful resource for Washington, DC health care consumers.

INTRODUCTION

The Healthy DC– Go Local project was submitted and accepted by the National Network of Libraries of Medicine Southeastern/Atlantic Region on November 27, 2007, with project funding to begin in January 2008. The two project managers were from different institutions (The George Washington University and Georgetown University), but had ties to the District of Columbia Area Health Sciences Libraries (DCAHSL) group, a local organization in the metropolitan Washington, D.C. area with both institutional and individual members involved in the field of health sciences information. Librarians involved in DCAHSL had been talking about a DC Go Local project for several years, and when it was finally a reality, members volunteered to select sites and perform data entry for the Go Local database, based on their areas of expertise and experience. The project became a collaborative effort between two institutions, several part-time staff who were hired, and a group of librarians from various DC area institutions/organizations/libraries.

BUILDING GO LOCAL

Recruiting and Training Volunteers

Because the DCAHSL group had been hoping for a DC Go Local project for years, many members were ready and willing to volunteer to work on the database once the project was approved in November 2007. The first call for volunteers went out on the DCAHSL listserv on January 28, 2008 (see the Appendix), with information about the project, potential responsibilities of volunteers, and dates/times of two training sessions, which were scheduled in February 2008. The DCAHSL group also met on January 28, 2008, and at this meeting the project managers announced the call for volunteers to select websites and perform data entry. Members who were interested in volunteering were asked to contact the project managers. Additionally, an announcement went out on the listserv for the DC Chapter of the Special Libraries Association on March 10, 2008.

In total, about 20 librarians volunteered to work on Go Local. Some of the volunteers received training via a “house call” since not all of the volunteers were able to attend the February training sessions, and some individuals volunteered after the training sessions had occurred. A “house call” involved on-site training at the volunteer’s place of work.

Because volunteers worked at a variety of institutions and had different areas of expertise, the goal was to match individuals with topics (Go Local Service Terms) that were of interest and within their area of focus. For example, two librarian volunteers from Children’s National Medical Center were assigned the topics of Pediatric Hospitals and Pediatricians, and a librarian working at the Community Transportation Association of America was assigned the topic of Transportation Services.

In addition to volunteers, the project managers were able to hire two part-time staff members to work on site selection, indexing, and data entry. The first staff member began work on the project in April 2008, while the second began in June. Both staff members were library school students and worked 20 hours per week, with the project grant allowing for six months of part-time work. Using the Local Service Term Priority Checklist (created by the National Library of Medicine) as a guide to the priority for entering local services for our area, the 40 priority 1 topics were assigned.

Critical Documentation

In order to guide data entry and ensure consistency among records, the project managers created a Healthy DC – Training Manual, which was used to train both volunteers and part-time staff members. The Manual included selection criteria (for websites and for health services without a web presence) and a style guide, as well as information (and examples) on creating site records and indexing.

The style guide was important so that data was consistent, but also to ensure against record duplication. For example, if an address in one record included “Street” and another duplicate record used “St.,” the database would consider these to be two unique records. Therefore, the guide included rules for names, addresses, phone numbers, URLs, and service/provider descriptions.

Additionally, the National Library of Medicine developed a Go Local Input System Manual, for use by all of the Go Local projects nationally, which covered a range of topics – from setting up the geographic service area to creating user accounts to inputting and managing database records. The manual described the entire Go Local system in detail and was used primarily by project managers to create the Healthy DC – Training Manual and to train staff and volunteers.

Time Well Spent: Building and Maintaining the Database

Much of 2008 was spent identifying local services/providers, creating database records, indexing entries, and reviewing work for quality and consistency. The records that were entered and approved grew month by month (see Table 1).

TABLE 1.

Monthly database record totals

Month	Pending Review	Approved Records	Incomplete Records
April 2008	53	23	153
July 2008	100	627	20
October 2008	19	1063	4
January 2009	13	1243	8
April 2009	13	1243	8
July 2009	0	1302	19
October 2009	0	1298	20
January 2010	0	1299	22

Before records could be considered complete, they needed to be reviewed and approved by someone other than the person who entered the information. Several volunteers took on the reviewer role in addition to their role as site selectors and indexers. If the reviewer had a question about a record or noted that a piece of data was missing, he or she could send it back to the person who created the record, including comments about the data in question. Each time a person logged into the database, they would see how many “returned” records they had and would need to address the issues before moving on to new records.

CHALLENGES ALONG THE WAY

Topic Assignment

The assignment of topics proved to be a bit troublesome in the beginning of the project, only due to a lack of experience in using the database. As mentioned previously, topics were assigned to librarians based on interest or area of expertise. While this plan sounded good in theory, in reality, it is difficult to isolate and index topics in a vacuum. For example, the topic of “Drug Abuse Treatment Centers/Programs” was assigned to a volunteer who indexed the term according to the topic area (as she was instructed). However, digging deeper into the services that such a facility provides, it became obvious that the database entry would need to include terms for all of the services that the facility provided, even if they overlapped with service terms assigned to someone else (such as Support Groups, Mental Health Clinics, etc.).

Indexing: Process and Problems

The issue of data consistency became a problem as the database was built. While the project managers created a style sheet as well as guidelines for data entry, consistency can be a problem when volunteers are somewhat geographically dispersed and work on the project sporadically. More challenging though, was the issue of indexing specificity; in other words, how many indexing terms should be assigned to each health service/provider. Each database entry was indexed by both local service terms and local health topics.

To take a step back, when indexing entries, the project managers, volunteers, and part-timers had to think about how users would be searching the database; they would have the option of searching for services by providers, facilities, and services, or by disease and health issues. As an example, the database entry for Washington Hospital Center (the largest private hospital in the District of Columbia) would include the local service term “Hospitals,” as well as terms representing all of the individual services/providers within the facility, such as “Neurological Surgeons” and “Emergency Medical Services.” Furthermore, for each local service term, indexers assigned local health topics (this would represent terms when users searched the database by disease or health issues). For example, the service term “Neurological Surgeons” was assigned to the following health topics: brain cancer, epilepsy, neurologic diseases, spinal cord injuries, and surgery. When a volunteer or staff member selected a local service term, the database suggested local health topics (automatic mapping) and additional health topics (suggested mapping), although other health topics could also be selected (other mapping).

Initially, the indexing did not seem as complicated as it turned out to be. The Washington Hospital Center was originally only indexed as “Hospitals,” as were all of the other hospital entries. As volunteers and part-time workers gained more experience indexing and using the database, the project managers realized that more entry points needed to be created for the hospital records, resulting in much more detailed records. With as many as 20 volunteers working on the project, it became more complicated as these types of nuances were discovered – old guidelines needed to be amended; previously entered records needed to be updated, and changes had to be communicated to everyone working on the project.

Time Commitments

While most of the Go Local volunteers were enthusiastic about working on the project, there were some who were not able to honor the commitment made regarding site selection and indexing for their topic. Because of the natural ebb and flow of professional work, it is often difficult to estimate the amount of time available to devote to a project, especially one where there is not a specific due date, or where the individual is not being evaluated. The problem this created was that certain topics which were assigned to people based on preference/area of expertise, were not completed in a timely fashion or needed to be reassigned. The project managers were under some pressure to accomplish a certain amount of work by specified dates, and when there are varying levels of obligation, often times the slack from one area must get picked up by another. Also, the project managers did not want to put pressure on volunteers to finish work, so often they needed to reassign topics without knowing the status of the original volunteer, or so that they could meet their internal goals regarding topic completion. Project managers often had to step in to cover a topic area assigned to someone else or spend many more hours working on the project than had been originally planned.

Auditing

Once records were in the database, they needed to be audited at least once every twelve months. This involved someone going into each record, reviewing the information for currency, and making sure the indexing terms were still correct (or adding new terms if there were new services). One of the biggest challenges for the project managers was keeping up with record auditing after the database went “live” in November 2008. Because the project budget only covered funds for part-time workers for six months, no part-timers were available after November 2008. Additionally, after the site went live, the number of volunteers who still had time for the project dwindled; the project managers were doing most of the auditing and were not able to keep up, as they each had their own full-time positions and were trying to fit in time to work on Go Local in their already busy days. While auditing was one of the most important aspects of database upkeep, this seemed to be the area which received the least amount of attention, due to lack of time to work on the project, and perhaps, the unrealistic amount of time that was originally thought to be needed on a weekly basis for database maintenance.

LESSONS LEARNED

Looking back at the project’s accomplishments and challenges, the lessons learned from the Go Local project relate to two areas – data consistency and indexing issues, and staffing and volunteer challenges. As mentioned above, the issues with data consistency and indexing were largely due to inexperience with the database, and perhaps not initially thinking through the process of how users would actually conduct a search and how this would dictate the indexing of entries. The project managers tried to approach the topic assignment very linearly but perhaps should have thought more broadly, considering how topics relate to one another instead of treating each as a separate entity. Jumping right into site selection, data entry, and indexing made sense; however, taking some additional time to understand the system and its components may have been beneficial. As the database grew and a better understanding of the relationships between topics was gained, it was necessary to go back, in some cases, to provide more specific indexing. One clear lesson that surfaced – documentation alone is not enough to understand complicated systems and relationships among services and providers.

After six months, the two part-time staff members who were temporarily hired for the project were no longer available. At first, the project was off to a fast start, as each part-timer worked 20 hours per week selecting sites and performing data entry. From working with these two staff members, the project managers learned that it was beneficial to work with on-site, paid staff members. Because they physically worked on the project at The George Washington University, the staff members could easily ask questions of one of the project managers or discuss uncertainties as they arose. The project managers also learned that library school students are hard workers; both of the staff members had excellent communications skills, were detail oriented, focused, and committed to producing high quality work.

Regarding the project volunteers, the project managers quickly realized that each person involved with Go Local had his or her own priorities and commitment to the project, which may or may not be the same as those of the project managers. Based on experience, this is simply the nature of working with volunteers. Perhaps the timeframe initially outlined for the project was too tight; perhaps there should have been extra time built in for bumps along the road.

Working with librarians from various institutions with diverse experiences is very rewarding. The project managers learned how valuable it can be to take advantage of other librarians’ expertise and insight. Additionally, while being flexible and adaptable are invaluable qualities, all those working on the database also learned that teamwork and dedication are critical in working on a large, long-term project. What were considered “challenges” were certainly not barriers to creating a database for DC area consumers.

CONCLUSION

While it truly took a village to build the database, project managers, volunteers, and part-time staff overcame bumps along the road to provide a resource built on collaboration, teamwork, and dedication. Despite the challenges mentioned above, Healthy DC – Go Local was a successful consumer health database, created by many dedicated individuals. With persistence and collaboratory initiatives, DCAHSL members achieved their dream of building a Go Local database to serve District of Columbia health care consumers. The project coordinators learned the value of perseverance, innovation, and determination and applied these lessons to the challenges of hiring part-time assistants, working with organizational bureaucracies, and managing volunteers. They utilized relationships that were formed in DCAHSL program meetings to obtain support from new organizations and individuals, such as non-profits, city agencies, and students.

Those who worked on the project were saddened when the National Library of Medicine announced in spring 2010 that they would no longer be supporting Go Local. The Healthy DC – Go Local website, as well as all of the other NLM-hosted Go Local sites, are no longer available online. The decision was made for a variety of reasons, including the lack of staff time required to maintain each Go Local site, low use at many sites, the inability of some sites to keep records current, shrinking library budgets that result in fewer resources to support and sustain sites, and NLM’s inability to increase funding levels due to a tight federal budget.