What is a Wiki, and How Can it be Used in Resident Education?

Abstract

Training as a radiology resident is a complex task. Residents frequently encounter multiple hospital systems, each with unique workflow patterns and heterogenous information systems. We identified an opportunity to ease some of the resulting anxiety and frustration by centralizing high-quality resources using a wiki. In this manuscript, we describe our choice of wiki software, give basic information about hardware requirements, detail steps for configuration, outline information included on the wiki, and present the results of a resident acceptance survey.

Introduction

wi·ki (wĭk'ē)

n. pl.wi·kis

A collaborative website whose content can be edited by anyone who has access to it.

[Originally an abbreviation of WikiWikiWeb, software developed by American computer programmer Howard G. Cunningham (born 1949): Hawaiian wikiwiki, quick+web.]¹

Educating radiology residents is a complex procedure that requires hours of self-study, an enriching didactic environment, and extensive clinical experience. Residents are increasingly expected to integrate information from multiple wide-spread sources including e-mail, multiple clinical systems, and Web pages. At our institution, we have four separate PACS systems, three different electronic medical record systems, an e-mail system, a department Web page, and several different hospital Web pages. Due to the near infinite flexibility and collaborative nature of wikis, they provide an ideal environment to combine references from several heterogeneous systems into a “one-stop-shop”. Additionally, because editing power can be delegated to users, they are empowered to change out of date information, improving the quality and timeliness of information when compared with a single central editor. While the validity and accuracy of material contained within wikis can be controversial, we have not had a single episode of malicious or improper editing over the 3 years the wiki has been in place. Even Encyclopedia Britannica recently announced that they would begin using a modified Wikipedia model¹³.

Wikis are becoming an increasingly important tool for collaboration as evidenced by several recent publications on the subject^2–12. To our knowledge, no one has described using a wiki as a collaborative tool for resident education.

This manuscript introduces the reader to wiki technology, describes our rationale for implementing yet another information system, discusses many of the decisions used to select a wiki software platform, details the types of information included on our resident wiki, and presents the results of a resident acceptance survey.

Materials and Methods

In this section we will detail software selection, setup, and configuration; server hardware; and our survey metric. Before planning implementation of this new Web page, we agreed on the following requirements: ability to leverage existing authentication mechanisms, support diverse content including file attachments and images, provide easy organization, be readily searchable, allow quick tracking of recent changes, provide a flexible structure for granting editing permission, and require minimal administrative oversight.

After an extensive review of available wiki packages, dokuwiki (http://wiki.splitbrain.org/wiki:dokuwiki) was chosen. Dokuwiki is open source software written in the PHP programming language, which is widely used on the Internet and can be run on a variety of server platforms including Windows, Linux, and Mac OS X. An active group of developers has updated and maintained the software since it was initially released in 2004. Dokuwiki's last software release was December 25, 2009.

One of the main features that led to the selection of dokuwiki is that it uses plain text files to store pages rather than a separate database server. Given our requirement for ease of setup and administration, the lack of a database has several advantages including fewer software packages to track and make sure are up to date, and simpler creation and restoration of backups. Since wiki pages are very lightweight with little markup, the over 300 pages on our server only constitutes 2.2 Mb of disk space. This is easily managed with a file-system-based architecture. Furthermore, dokuwiki automatically maintains an index to provide fast searching in the absence of a traditional database. Even with limited server hardware (see Discussion), search requests over the entire server are completed in milliseconds.

The process for server software setup after operating system installation is as follows:

1. Installation and configuration of a PHP compatible Web server (we chose Apache)

2. Installation and configuration of PHP

3. Installation and configuration of dokuwiki software

4. Custom development to integrate with the existing authentication infrastructure

Steps 1 to 3 required less than eight person hours. While we could have stopped here and had a working solution using dokuwiki's capable user management framework, we strongly felt that integration with our existing university-provided authentication was paramount for adoption. The open source nature of dokuwiki allowed us to easily accomplish the necessary custom integration with approximately 200 lines of code and only ten person hours from an experienced PHP programmer.

Dokuwiki's permission system allows administrators to restrict the ability to read, create, edit, and delete pages as well as the ability to upload file attachments on a per-user, user group, or IP address basis. This allows granular control over access to the Web page and protection of sensitive content including resident phone numbers and addresses. IP address authentication is useful such that many pages are accessible without a login by virtue of using a computer within the hospital. We have user groups for residents, fellows, and faculty as well as other support staff.

Server hardware requirements for dokuwiki are minimal. Our initial server was a repurposed desktop computer—Pentium II processor with 256 MB of RAM and a 20 GB hard drive running Red Hat Enterprise Linux 6, Apache, and PHP. After a 6-month trial period, the wiki was moved to a department server—Quad-Core Xeon 2.8 GHz server with 4 GB of RAM, 60 GB RAID-1 hard drive array running Windows Server 2003, Apache, and PHP. The move was performed to integrate the wiki into the department's existing windows backup routine, rather than due to performance issues. There was no noticeable performance increase with the move, indicating the low hardware requirements of dokuwiki.

In order to assess the wiki's effect on the residency program, we designed a survey to measure resident use, as well as participation in editing and maintenance. The survey questions are listed in Table 1. The survey was distributed over e-mail, and responses were tabulated in a blinded fashion.

Table 1.

Survey Questions and Responses

Question	Response
What is the wiki address?	Correct—51/51 (100%)
Have you visited the wiki?	Yes—51/51 (100%)
Have you added or edited content?	Yes—35/51 (69%)
How many times per week do you access the wiki?	5.6 ± 4 times
Do you know how to add a new page?	Yes—19/51 (37%)
Do you know how to edit a page?	Yes—40/51 (78%)
Do you know how to see a list of recent changes?	Yes—22/51 (43%)
Do you plan on adding content in the future?	Yes—36/51 (71%)
How useful is the wiki?	4.7 ± 0.5 (Likert scale, 5 being very useful)
What information do you access the most?	see Fig. 1

Results

Fifty-one out of 60 residents responded to the survey (85%). All responding residents correctly identified the wiki URL and reported having visited it at least once. On average, residents reported visiting the wiki 5.6 times per week with one resident reporting 20 times per week. Most residents (78%) reported knowing how to edit an existing page; however, far fewer reported knowing how to add a new page (38%). Despite such a large percentage of residents reporting how to edit, only 35 (69%) had edited content. Due to the flexible nature of a wiki, it is important to stay up-to-date by scrolling through the list of recent changes occasionally. However, only 43% of residents reported knowing how to find recent changes. A majority of residents planned on adding content in the future (71%). On average, residents thought the wiki was very useful (4.7 ± 0.5; Likert scale, 5 being very useful).

In order to evaluate the highest yield information for a resident wiki, those surveyed were asked, “What information do you access the most?” Their free responses were grouped into the following categories: phone numbers, dictation templates, rotation/call information, educational content, schedules, and others (useful links, policies, etc.). There was no limit to how many references a resident could list. The median number of categories listed by respondents was two. Percentages of the total votes were calculated and are displayed as the dark gray bar in Fig. 1. To validate the survey results, the server logs were analyzed for a 4-month period. Hits from the logs were assigned to the same categories, and a percentage was calculated and displayed as the light gray bars in Fig. 1.

Fig. 1.

What do you access most versus server logs. Free responses from residents and hits in our server logs were grouped into the following categories: schedules, phone numbers, dictation templates, educational content, rotation/call information, and others, and graphed as a percentage of the total.

A screenshot of our wiki (http://www.indyradres.org/) is included in Fig. 2. There are two key features of the main page—the sidebar and the recent changes link. The sidebar on the right is another wiki page that can be changed and edited like any other, but is translated into a side menu that persists on every wiki page. The recent changes link (right hand side of Fig. 2) presents the user with a list of the changes that their current login status allows them to access (Fig. 3). The most frequent maintenance task is moving pages from one location to another more appropriate location in the wiki hierarchy; this can be easily monitored and fixed using the recent changes page. Note that the recent changes page also documents who last modified a page, although these details have been blurred in the figure for privacy concerns. Completely unauthenticated users are not authorized to edit information on the wiki, and thus, residents are accountable for their changes. Dokuwiki also keeps a configurable number of page revisions. The current version of any page can be compared with a prior revision by clicking on the red/blue eyeglasses. This generates a differences view (Fig. 4) that allows for easy selection of the best document version and identification of inappropriate modification.

Fig. 2.

Landing screen. Screenshot of the initial landing page for the resident wiki. Note the sidebar on the right that contains links to nearly all of the content on the wiki. Also note that the sidebar is organized according to access restrictions with the second category open to everyone within our department.

Fig. 3.

Recent changes. Screenshot of the recent changes screen of the wiki. Scanning for recent changes is an important feature of maintaining and using a wiki. This screen documents not only identifies the pages that have recently been changed, but also identifies the user who last edited each page. Clicking on the sunglasses icon takes the user to the difference view (Fig. 4).

Fig. 4.

Differences view. Screenshot of the differences view that allows a user to compare two versions of the current page. The differences view is important for editing and tracking document revisions. The left column shows the previous version of the file, while the right column identifies differences with + for added lines and − for removed lines in addition to color coding.

Discussion

We attribute much of the success of the wiki to the quality of the content. During the early days of our wiki, there was a push from the chief residents to include what was expected to be high-yield content including rotation and call schedules, phone number listings, and general on-call help. In our environment, the rotation schedule is created and maintained by the chief residents, and they are responsible for maintaining this information on the wiki. Call schedule information is managed by several of the administrative assistants in the department who have been trained to edit wiki documents. As expected, these categories were the top accessed URLs and survey responses (Fig. 1).

Another attribute that has been critical to the wiki's success has been the presence of appropriate user authorization and administrative oversight. In our department, the two chief residents maintain the wiki with daily surveillance (looking for spurious edits) and adding new content. This process involves reviewing the recent changes link as detailed above. Over the 3 years that the wiki has been running, we have not had a single episode of malicious editing.

Using open source wiki software has also contributed to the success of the project. Access to the source code and community support for plug-in development allowed for easy integration with the department user authentication system, decreasing barriers to use. Finally, the human and hardware costs associated with implementing the wiki have been low, including 18 h of server setup and use of inexpensive server hardware.