If you are new to data management or if you are just thinking about a change within your disability resource office, the range of options and approaches to data collection can be overwhelming. Just read the posts on recent AHEAD and DSSHE listservs and you’ll see questions such as these recent queries:
- Does anyone use Banner for tracking students with disabilities? Can I keep disability data confidential?
- We are looking at electronic options for tracking student appointments, parent phone calls, and faculty technical assistance. Does anyone have suggestions?
- We are using paper based files, but our new VP wants all offices to go electronic. What do I need to be aware of as we make this transition?
Today there are a range of options for managing data that support the work of a disability resource office. No single approach is right for all campuses. Read more about the four types of data management that are available or scroll down to the table below to consider this continuum of options and some of the factors that may help you find the approach that’s right for you.
An Overview of Data Management Approaches
(1) Paper/Electronic Files
These are hard copy files, often complemented with electronic documents and spreadsheets that may be stored on a local machine or shared within the department.
This approach is less compatible with multiple campus systems in which students may be simultaneously enrolled in more than one location. There can be a potential for either delays (as hard copy file information is shared from campus to campus) or duplication and potential lack of internal consistency (if hard copy files are maintained in multiple locations). Spreadsheets and documents can make information more searchable, but the information is not easily related to other data without additional manual steps. Also, students are more likely to need staff assistance with this model. There may be some self-service features offered (such as online forms to request letters or appointments) but these are typically bridges to manual tasks that require considerable staff time to complete.
(2) Internal Database – built for accommodation management but can be less robust
These systems are often built in-house and may run off local machines or off the network of the college or university. They are often used in conjunction with hard paper copy files.
With an internal database there is a potential to create a system that is truly designed specifically for the unit that will use it. There can be a high degree of control over the design and use, however these systems can become difficult to scale-up or keep functioning well if the original designer is no longer available to provide maintenance or if the platform itself becomes inoperable or not able to connect well with other institutional tools. These systems can work exceedingly well if there is dedicated talent to maintain the application, but they may run the risk of cementing current practice rather than opening dialogue around potentially important shifts in practice.
(3) Institutional Database – not built for accommodation management but provides shared reporting
Many institutions have robust student data systems. These systems often contain student demographic information as well as information related to registration and financial aid. At some institutions, disability related data is stored as well.
Using the institutional student data system can be an attractive option given that it does not require additional investment, there is system support, and information can be available for multiple reporting functions. However, it can also be a difficult choice given the challenge of striking an appropriate balance with which information will be stored and shared. There is a potential for staff as well as student and faculty access but the interface design would need dedicated support to maintain in an accessible and user friendly manner.
(4) Third Party Database – built for accommodation management and informed by best practices in field
These systems are developed and supported by a third party. They can be offered as software that is purchased and deployed on local hardware or as software as a service accessed online. These systems may be used to design a completely paperless workflow.
Ideally, these systems are designed specifically for use by those working in the field of disability in higher education. Ideally, access technologists and accessibility analysts inform the design to ensure they are accessible and intuitive to use by students, staff, and in some cases faculty as well. Customized reporting features ensure robust information is shared without risking unauthorized release of confidential information. Data is backed up and available via secure internet connections, with dedicated support and continuous improvements.
A Continuum of Data Management Approaches
| |
Paper/ Electronic Files |
Department Database |
Institutional Database |
Third Party Database |
| General Description |
Hard copy files, often complemented with electronic documents and spreadsheets that may be stored on a local machine or shared within the department. |
These systems are often built in-house and may run off local machines or off the network of the college or university. They are often used in conjunction with hard paper copy files. |
Many institutions have robust student data systems. These systems often contain student demographic information as well as information related to registration and financial aid. At some institutions, disability related data is stored as well. |
These systems are developed and supported by a third party. They can be offered as software that is purchased and deployed on local hardware or as software as a service accessed online. These systems may be used to design a completely paperless workflow. |
| Interface |
There are physical files with pieces of paper that individuals use to hand write and visually read information. There may be word processed documents that are saved, edited, and printed. These documents are often located in folders on a local or shared network drive. There are often spreadsheets to enter information and track services as accommodation is approved and implemented. |
There may be physical files, but typically there is a computer login process to enter an interface that has been designed as a front-end for the database. There is enormous variety in the design of these systems. Some are created with direct end-user input, creating highly customized offerings. Others may be created by individuals with limited skills. The front end user interface as well as the backend database will need to be maintained over time which can be a challenge with turnover in personnel. |
The interface for the institutional database serves the needs of general classes of users. If the institutional infrastructure is in good shape, and the network and enterprise level applications are deployed well, then the options for customizing screens within the institutional database may be attractive. Permissions can be managed to allow only designated personnel to access information related to disability and eligibility for accommodation use. |
Third party systems should exhibit a high degree of savviness with the interface they design. Because these systems are built specifically for use by disability resource personnel, they should offer intuitive access to information that is used on a daily basis. They should also afford institutions the ability to customize the experience of disability services personnel, testing center personnel, library, faculty, distance learning, facility services, and others who have a need to know specific information. |
| Analyzing and Reporting Data |
Manual efforts are necessary for most processes and outputs. |
Variable - Useful reports could be built into the system but in the absence of customization over time, the system can get out of sync with needs. |
A variety of reports are often available for given classes of users, but writing reports may require the time of experts who may not be readily available. |
Reports should be built into the system but there should also be a high degree of customization achievable by the local personnel. |
| Student Access to Information |
Students are given hard copy documents and/or emails. If the department had access to IT services there could be online request forms as well. |
Students are given hard copy documents and/or emails. If the department had access to IT services there could be online request forms as well. |
Students could have an accommodation channel in the institutional portal. This is not common practice. It could lead to support personnel in non-DS areas seeing disability status. |
Some of these systems have students login through an interface that is designed specifically for them and uses their existing college or university credentials. |
| Cost Considerations |
Minimal in terms of equipment or licensing fees but can be high in terms of personnel time. |
Potentially initial costs for labor to build the system, then ongoing maintenance for database plus equipment. |
Minimal costs aside from potential use of programmer time for customizations. |
Variable depending on size of institution and scope of service. |
| Security and Confidentiality |
Hard copy files can be locked, but are at risk from fire or flood. Electronic documents should be passworded and backed up securely/regularly. |
These systems may become prone to failure if not maintained properly and should be backed up regularly to avoid data loss. |
These systems house significant sensitive data and are backed up and protected as standard business. Permissions may be managed by multiple entities. |
These systems house significant sensitive data and are backed up and protected as standard business. Permissions should be managed by disability personnel. |
| Time Considerations |
All processes require time of personnel. |
Variable - a well designed system could be quite efficient, a poorly designed system could require significant time. With additional effort, the system could integrate further. |
Variable - with use of skilled programmers, an institution could create a highly automated and efficient system that integrates workflows seamlessly and affords personnel time to work on substantive projects. |
Third party systems should be providing automation and efficiency. Many of the systems will integrate with institutional systems for student data and communication to afford personnel time for substantive project work. |
| Sustainability and Practice Improvement |
Knowledge of system is often transmitted informally but may be recorded in training guide. Improvements can often be made quickly but may be in place only as long as current practitioner - little institutional commitment. |
Departments or department specific database creators may create a training guide. Ideas for improvements to system may be easy or hard to implement depending on institutional climate and level of dedicated support for department specific resource. |
Training guides for many aspects of the core database may exist but disability specific screens may have limited documentation. Institutions with the best interfaces may be using modifications to achieve user friendly approaches which are hard or impossible to share. |
Third party typically provides some documentation or community of practice, and often also provide options for training. Institutions using the same third party system can also share ideas and work together to develop feature requests. |
Contributed by Kaela Parks, Director of Disability Services, Portland Community College.