Next Article in Journal
A Fuzzy Inference System for Unsupervised Deblurring of Motion Blur in Electron Beam Calibration
Next Article in Special Issue
Comparison of the Changes in the Structure of the Transverse Arch of the Normal and Hallux Valgus Feet under Different Loading Positions
Previous Article in Journal / Special Issue
Active Compact Wearable Body Area Networks for Wireless Communication, Medical and IoT Applications
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Design and Development of a Web Application for Matching Drug Addiction Treatment Services with Substance Users

by
Sachin Hiriyanna
1,
Miyuki F. Tedor
2,
Patricia A. Stoddard-Dare
3 and
Wenbing Zhao
4,*
1
Earny Inc., 1728 Olympic Blvd., Santa Monica, CA 90404, USA
2
Department of Criminology, Anthropology, and Sociology, Cleveland State University, Cleveland, OH 44115, USA
3
School of Social Work, Cleveland State University, Cleveland, OH 44115, USA
4
Department of Electrical Engineering and Computer Science, Cleveland State University, Cleveland, OH 44115, USA
*
Author to whom correspondence should be addressed.
Appl. Syst. Innov. 2018, 1(4), 47; https://doi.org/10.3390/asi1040047
Submission received: 12 September 2018 / Revised: 24 November 2018 / Accepted: 26 November 2018 / Published: 30 November 2018
(This article belongs to the Special Issue Healthcare System Innovation)

Abstract

:
One of the current and biggest problems in the system of emergency care for the drug overdose epidemic is the failure of information delivery on nearby treatment facilities. Even though some initiatives have tried to solve this issue, they either failed in delivering the information or in providing good usability. This paper presents the design and development of a web application that we refer to as DrugHelp.Care. This application delivers highly accurate, easy-to-understand, and targeted information in a timely manner for substance users and their well-wishers. It also provides an ecosystem for the treatment facilities with an easy-to-use interface to constantly update their complex information along with automatic email reminders and data completion progress indicators. Based on the requirements we have collected from substance users and treatment facilities, the application is designed and developed using the LAMP stack. A search engine for the substance users and their well-wishers preserves complete anonymity, which is very important to ensure the confidentiality of substance users.

1. Introduction

More than 64,000 Americans lost their lives from drug overdoses in 2016 alone [1], and this number is increasing. Many of these lives could have been saved if either the substance user or their friends or family members were able to quickly reach out to treatment facilities in a timely manner [2]. Timely access to care has always been a major problem in substance-abuse treatment [3], where a significant number of patients wait more than a month to receive treatment [4], and wait time is often noted as the major obstacle to recovery [4]. Many patients are turned away or not able to receive necessary care immediately at treatment facilities [5]. A problem lies in the fact that treatment facilities are often either hard to locate or mismatched to the needs of those who are seeking treatment. For example, some treatment facilities do not accept pregnant women and such information might not always be known to the people until they get to the facility physically or talk to someone on the phone [6]. Many substance users experience a short window of time when they are willing to engage in treatment voluntarily [7]; thus, this difficulty can be a significant roadblock to recovery. The difficulty in finding an available substance-abuse treatment facility also prevents others who meet substance users, including law enforcement officers, social workers, and medical/emergency personnel, from connecting substance users with available treatment [8,9]. In part due to the time intensive process of locating an available treatment facility, substance users are often directed back out to the street to find help on their own, even after an overdose and the use of naloxone. Substance users who want to stop using, however, should not be discouraged from seeking help, and thus delaying recovery and risking overdose, because of the difficulty in locating available treatment options. This is especially important for high-risk groups such as pregnant women, racial/ethnic minorities, those who are on public assistance, homeless, or with a criminal justice referral [10]. We believe that one of the solutions to the opioid epidemic is to remove this roadblock and make information about available substance-abuse treatment options accessible in a timely manner.
There are several web applications that offer a searchable list of treatment facilities; however, they lack in providing accurate information on availability, waitlists, or other service specific information such as admission criteria (e.g., insurance plan). Thus, there is an urgent need for a centralized system that enables dynamical update of such information by the treatment facilities so that patients can find up-to-date and accurate information for the best treatment available. Studies indicate that improved efficiency in delivering care can shorten the wait time for patients in ambulatory and community health services [11,12,13,14]. This article presents the design and implementation of a web application, which we refer to as DrugHelp.Care, that fills this need.
Prior to the implementation of the web application, we carefully investigated the needs of substance users and their caretakers, and the needs of the treatment facilities by completing numerous interviews and focus group studies. Through these efforts, we finalized detailed user requirements and the corresponding user interface designs. We also considered the trade-offs between a web-based front-end application and a cloud-supported native mobile application. We decided to develop a web-based front-end application instead of a mobile application because the former can be accessed by both mobile devices with a web browser and by desktop computers/laptops [15]. The web page is designed in such a way that it automatically adjusts its content layout based on the devices in which it is displayed. To reduce development and long-term maintenance cost, we chose to use the so-called LAMP stack [16], which consists of the Linux operating system, the Apache web server, the MySQL database, and scripting languages Perl, PHP, and Python.
The web application is fully functional and is publicly available at http://drughelp.care/. Supported by both internal grants and one external grant from the Woodruff Foundation, we are currently actively recruiting treatment facilities to use our web application to provide a better service to millions of substance users. Our goal is to save lives by making it easier and quicker for substance users to find and receive the right treatment faster.

2. User Requirement Studies

There are two types of users for our web application: substance users and their family members and friends, and treatment providers and first responders who want to find available, compatible treatment options for clients seeking substance abuse treatment.
Through our needs-based study, we found the following gaps from the point of view of substance users who wish to find treatment: (1) The substance users would not know the admission policies and whether the treatment facility would accept their condition. For example, a treatment center might not admit any patients who are pregnant or patients who are on Medicaid; (2) The substance users would not know the availability or the wait time of a particular treatment or service unless and until they make a phone call to every facility that they are interested in; (3) Existing websites are often very cluttered and maybe filled with ads or other web components, which could confuse substance users and make it very difficult for them to find the right treatment facility; (4) Existing applications do not offer a way for a user to make a phone call to a treatment facility by simply clicking a link in the application.
The following gaps have been experienced by treatment facilities with existing applications: (1) No dashboard or administrative panel for the treatment facilities to manage their data; (2) No option on the existing discovery platforms for the treatment facility to update their availability and waitlist for each and every drug-related treatment service; (3) No option for the treatment facilities to visualize the data entry progress for every service they register; (4) No option for the treatment facilities to add contact persons to get scheduled reminders to update the data on treatment services; (5) No option to register a treatment service with multiple time or location-based sub-services.
To address the problems identified by substance users, the following features are considered to develop within the Web application as preferred solutions: (1) To show the availability and waitlists for admission dynamically; (2) To show the constraints on or restriction for admission to particular treatment or service; (3) To provide accurate information, verified and updated by treatment facilities themselves; (4) To provide quick access buttons such as call, directions, or website; (5) To provide clean web design to help those who are in need for substance-abuse treatment to get help without any confusion; (6) To provide options to filter and sort the list of treatment facilities based on various attributes including availability and waitlists; (7) To provide a flexible design that supports both traditional computers and mobile devices.
To address the problems reported by treatment facilities, the following features are considered to develop within the web application as preferred solutions for treatment facilities: (1) To develop a dashboard for administrators; (2) To provide the option to register, update, and delete a service; (3) To provide the option to register multiple sub-services under a service based on location and hours of operation; (4) To provide the option to add multiple contact persons to a particular service; (5) To send email reminders to constantly update the availability and waitlists of the treatment services; (6) To show a data entry progress indicator for every service that is registered.
The web application that is the closest to ours is EmeraldJennyfoundation.com [17]. It was founded in 2017 to solve the challenge of discovery of substance use treatment facility. Its search feature can filter for outpatient, residential and Medication Assisted Treatment options. However, the website lacks detailed information on the type of service offered, restrictions and requirements (e.g., insurance), and other criteria that are used to determine the eligibility. Furthermore, it does not provide up-to-date availability and waitlist information dynamically.
In addition to the above high-level user requirements, we also decided on a set of lower level features after interviews and focus groups with the look and feel of the treatment search pages that have clean and comfortable user interface design. The following are the design characteristics to consider while designing the user interfaces: (1) Minimal use of colors; (2) Use of non-flashy colors; (3) Loosely placed user interface components; (4) Enough room to perform mouse click; (5) Less or zero auto-changing contents; (6) Easy navigation between components; (7) Collapsible components to hide unwanted text; (8) Highlighting important buttons.
The treatment facilities will be required to enter information about their services during the process of signing up with our web application for each of the treatment services and sub-services they are offering. Since the whole application depends on complete and accurate information about each service provided by a treatment facility, efficient user interfaces are needed to help treatment facilities understand every step of the sign-up process. The following lists the characteristics for treatment facilities as part of the application: (1) To easily register one or more services at a time; (2) To easily understand the complete flow of registration; (3) To show bird’s eye view of huge dataset of services to select from; (4) To provide data completion progress indicators; (5) To provide feedback on all important step; (6) To remind the contact persons to update the information periodically; (7) To provide an easy and efficient interface to contact persons; (8) To easily manage and update each service detail; (9) To easily navigate between services; (10) To provide good security on the data that they are entering; (11) To secure the administrator’s account with best practices in user authentication; (12) To provide an email notification each time the account information changes; (13) To provide all the utilities to completely authorize a contact person to add a service or update a service; (14) To secure the administrator’s account from cyberattacks.

3. System Requirements

In this section, we elaborate on system requirements for our web application. These include the specification on the operational conditions as to how it is going to be used and development constraints like what programming languages to use, which server or database to use, and what architectural pattern to follow.

3.1. Application Development

We choose to use a well-known efficient Cascading Style Sheets (CSS) Framework called Bootstrap to develop our web application. By using such a CSS Framework, we can deliver users with the best experience possible whatever the device they are using.
Bootstrap [18] is the most popular and advanced CSS Framework to build web applications. It is not only easy to learn and implement but is also very efficient in terms of the responsiveness of web components on various devices with different screen sizes. Hence we can take advantage of these features to build a web application such that can work seamlessly on the mobile devices. Bootstrap follows the twelve column Grid system and a series of containers, rows, and columns to layout and align the contents. It is built using flexbox [19] and is fully responsive to all screen sizes. Bootstrap is supported by all major mobile and desktop web browsers.
Front-end development: The DrugHelp.Care web application front end may require constant design changes based on the feedback we have collected from substance users and treatment providers. For this reason, it is important to use a CSS Framework because it provides us with the flexibility to reuse components and modify the design of entire application from a single file.
Back-end development: It is very important for us to build an application that is scalable and easy to maintain. For this reason, we have chosen a development stack that is widely used and has good support on the Internet.

3.2. Web Hosting

Web Server: Since the Web application deals with a large amount of data with complex database transaction and queries, it is required to choose a server that can handle good amount of computation and can handle the load when hundreds or thousands of users access the applications concurrently. For this reason, it is wise to choose a server that is auto-scaling, load-balancing, and has the option to pay as per the usage.
Email Server: We need an email server that supports the Simple Mail Transfer Protocol (SMTP) and message encryption techniques. Furthermore, to avoid using blacklisted servers accidentally from third parties, it is always good to create a brand-new instance of email server. This approach will give us the confidence that the emails will not end up in spam folders.
Database: It is important to choose a relational database that offers all the advanced features for database queries such as constraints, joins etc., and provides a user interface to visualize the data in schema.

4. Software Design and Planning

Software design is a process of translating and visualizing the user requirements, which will help the software developer to clearly understand the exact needs of end-users. Whereas software planning is the process of planning the development of the software application completely by defining the time and cost of the software application. For conciseness and to avoid confusion, we use “Agency” to refer to treatment facility that uses our web application to enter relevant information, and “User” to refer to substance users or their caretakers who use our web application to find treatments/services.
Figure 1 shows the major components of the web application. The agency will upload the data on their dashboard, while a user will get to view and search the data. An agency is expected to enter the type of treatment and services it offers and the corresponding patient admission criteria. Furthermore, the agency will also enter the number of available beds for each treatment and service. If no slot is available for the service, the agency will indicate the number of days that the user will need to wait to get the service. The user could then see what treatment and services are provided by the agency and the corresponding availability and wait time. In Figure 1, we included common types of treatment and services. Service types include assessment, clinically managed residential, intensive outpatient program, medically monitored inpatient, outpatient, partial hospitalization, and sober living. Additional services include needle exchange programs, locations to get naloxone, Hepatitis C testing, HIV testing, case management, among others

4.1. User Interface Design

User interface (UI) is the front-end part of the application where the end-users can perform interactions with the back end through graphical user interface (GUI) components such as buttons, text field etc. Because this web application is designed for substance users and treatment providers, we strive to make sure that the UI is clean and web components are properly placed in each page.
While we know exactly what information to collect from agencies and what information we want to provide to the substance users, how to collect the information and how to present the information remain critical for the success of the web application. To design the most intuitive UI for the actual stakeholders, i.e., the substance users and the agencies that will be using our web application, we spoke with over 100 of them. Because these stakeholders are not technical persons, we brainstormed with them on how they would use our web application in terms of user stories on a whiteboard. This step is critical for the adoption and efficacy of our application. Figure 2 shows the final main user story we have come up with. The main user story starts with the home page of the web application, as shown in step 1. The page shows two buttons in addition to our project title DrugHelp.Care. One button named “search” is intended for users to find the right agency to receive treatment or service. The other button named “agency” is intended for agencies to register and update their information. Because the web application must secure the support from agencies before it can be used by the users to find available treatment or service, in step two, we assume that an agency would sign up with us. Once the agency has signed up, it will then proceed to step three to register every service and treatment the agency provides, and possibly a set of subservice or sub-treatment under each service or treatment. Then, in step four, a user could search for an available treatment or service in the search page.
Accordion is a web component that extends the cards container of Bootstrap in which organizes content within collapsible items. We choose to use Accordion to manage the web view area of the DrugHelp.Care web application because it allows one to expand only one collapsible item at a time.
Figure 3 shows an example display of collapsible items using Accordion. When the “Assessment” tab is expanded with its children, all other tabs, i.e., “Referral” and “Walk-in assessment”, automatically have their children collapsed and hidden. This mechanism saves the space needed to display the options, which is important when a user accesses DrugHelp.Care from a mobile device. Furthermore, this mechanism highlights the items where the user is operating on a web area, which is more conducive for user interaction with our web application.

4.2. Database Design

Figure 4 shows the eight tables in the database, and the relationship model of the database for our web application. The Registered Service table, Contact Person table and Password Reset table each has a foreign key on the Agency table, whereas the Registered Service Dataset table has a foreign key on the Registered Service Offering table which in turn has a foreign key on the Registered Service table. The Registered Service table contains the identifiers of the Service that is defined in the Service Parent and the Service Child tables.
The agency table is used to store account information of registered agencies. The Service Parent table is used to store the set of all services that agencies can choose from during registration. The Service Child table is used to store the set of all sub-services that agencies can choose from during registration. The Registered Service table is used to store all the registered services from an agency. The Registered Service Offering table is used to store all the service offerings of an agency based on the time or location. The Registered Service Dataset table is used to store all the data for each service offered by an agency. The Password Reset table is used to store all the password reset requests with unique Uniform Resource Locators (URLs). The Contact Person table is used to store all the contact person’s information for each service of an agency.

5. Implementation of DrugHelp.Care Web Application

5.1. Software Development Environment and Tools

To implement the DrugHelp.Care web application, we used the Atom Integrated Design Environment (IDE) for software development and debugging. We used CyberDuck SFTP to transfer files to and from the Web server to the local computer. We used DataGrip as the database client to visualize the schema of the tables. We used PHPMyAdmin to access the production database on the Web server through the Hyper-Text Transfer Protocol (HTTP).

5.2. Version Control

A Version control system is a tool that allows us to track the iterative changes we make to our code base. It is an important tool for any software developer because it allows us to revert back to a previous version of the code base anytime when it is required and allows us to let more developers collaborate during the application development. Moreover, we can have different branches of the repository with different versions of the code base, which enables us to compare and differentiate between the code base of different versions. We chose to use GitHub as the tool for version control.

5.3. Implemented Web Pages and Use Cases

In this section, we outline key pages and some use cases to demonstrate the functionalities of the DrugHelp.Care web application. The example web pages and the explanation of their usage are provided in the Appendix for clarity.
  • Homepage. The DrugHelp.Care web application starts with the homepage. The page is clean and clear. It is not cluttered, and it is not confusing. It consists of only two main buttons, one for use by substance users and another for use by agencies.
  • Searching for service. The search page is used by substance users, their friends or family members, and treatment providers. They can look for emergency care or treatment facilities in a timely manner with accurate and updated information.
  • Treatment facility account sign-up. We assume that each agency has an administrator who will sign up their services by providing all the contact and location information including administrator’s email address.
  • Agency sign-in and password reset. After an agency signs up with our web application, the corresponding administrator is asked to sign into the account using the registered email address and the password chosen by the administrator. If the user forgets the password by any chance, the person could click the link provided on the sign-in page to reset the password.
  • Agency dashboard. The DrugHelp.Care web application offers a dashboard for each registered agency to register new services, update existing services, provide availability information, and set conditions for admission for each registered service.
  • Periodic update on service availability. Our web application automatically generates and emails a reminder to the administrator of each service for the person to update the availability of the service and wait time (if the service is not available) at a predefined frequency (typically daily). Periodical update of the service availability is important for users to find accurate information for the best available treatment.

6. Usability Study Result

We managed to conduct a small-scale human subject study on the usability of our web application. Three individuals experimented with entering the daily update of wait time and availability. Two individuals experienced the registration process. Three individuals tried out our web application to search for aftercare for their clients. All eight participants are 30 to 50 years old female employees at a hospital. Below we summarize their opinions regarding the questions we have asked. For each question, we asked the participant to give an opinion in a scale of 1 to 5, with 5 being the most favorable.
Question 1: For the treatment service search functionality, do you agree that the filtering criteria are adequate? All of them rated 5. However, they did suggest adding some criteria for filter, and we will be adding them for the next release of our application.
Question 2: For the treatment service search functionality, are you happy with the quality of the search result (i.e., the most desirable result is up front)? All but one person gave a 5 rating. The one person who rated a 4 thought that the languages used for the website were too technical.
Question 3: Regarding the daily update of the available services, how do you rate the helpfulness of the daily email reminder and the direct link to the update page? All participants rated 5. They said that the update is easy and they do not have anything that they think we should change.
Question 4: Regarding the input process of the services/treatment, how do you rate the helpfulness of the progress bar? This feature received lower ratings (3 and below) because the progress bar shows incomplete when the agency left some sections blank because such sections do not apply to the agency. We will add an option for “not applicable” to solve this problem for the next release of our web application.
Question 5: If you have experimented with accessing our web application using a mobile device, how do you rate the UI design (ease of access to information and data input)? All participants gave a 5 rating. They all liked the mobile interface. It is virtually the same as the desktop web interface, except that the filter shows up at the top.
Question 6: If you have experimented with accessing our web application using a desktop/laptop computer, how do you rate the UI design (ease of access to information and data input)? All participants rated 5. They thought that the website is much easier and straight forward to use compared to other websites with similar services. The only one “complaint” was that the particular hospital used an old Internet Explore browser, which did not work well with the website, so they had to use Google Chrome instead. There is nothing we can do about this.
Question 7: What is your overall rating for the usability of our application? All but one gave a 5 rating except the one person who gave a 4 rating because she deemed the application too technical. However, we think she misunderstood our project. We explained that the current phase of the web application is meant to be used by medical professionals, and we are currently developing another one for use by the general public.
As can be seen from the result, the web application is well received in general. We did find one area of improvement on the progress bar design, which will be fixed for the next release of our web application.

7. Limitations

The Web application was designed and implemented in the first phase of our project. This application establishes a solid foundation for the project to move forward, but it lacks any fancy features and functionalities. In the next phase of this project, we plan to address several limitations of our current application:
  • We currently require a dedicated person to manually update the availability of services. With enough training data, it is possible to predict the availability of each type of services using machine learning algorithms [20,21,22]. This would alleviate the burden from treatment facilities having to assign a dedicated person to manually update the service availabilities and minimize the associated human errors such as forgetting to update or accidentally providing incorrect availability information.
  • We currently rely on the substance user or his/her caretaker to select the best facility. This could be a daunting task considering the many factors that one would have to consider, such as insurance coverage, distance from home and traffic situation, types of services needed and offered. Without asking the user to disclose his or her private information, it is difficult to recommend the best treatment facility to a user. In the next phase of the project, we will aim to strike a balance between privacy protection and the usability of our application. For example, if a user is willing to provide the confidential information that is needed, we could offer to recommend the best treatment facility that fits the user.
  • The Web application that we developed requires continuous Internet connection to function. In the next phase of our project, we plan to develop a native mobile application that runs on both Android and iOS platforms. The mobile application could cache available services and allow off-line search.
  • Peer support has been proven to be effective and it is essential in improving retention for drug treatment and reducing the likelihood of relapses. Our application currently does not have any feature in enabling peer support. We plan to add a social networking feature for substance users to help each other anonymously in our application.

8. Conclusions

This article presented the design and implementation of DrugHelp.Care, a web application for use by substance users to find the most desirable service and for treatment facilities to enter the services and treatment they offer. The design of this application was based on the findings of the gaps in existing applications for substance users and treatment facilities. We intentionally implemented the system as a web application for maximum portability across traditional computers and mobile devices. With a careful design for clean and clear user interfaces, the application enables the treatment facilities to update the availability of each service they offer frequently so that substance users could find the most desirable service that is available to them. Finally, we should note that we are actively improving the DrugHelp.Care web application based on user feedback and the project needs. What readers see at http://drughelp.care/ at a later date might not be exactly the same as the screenshots shown in this article.

Author Contributions

M.F.T. and P.A.S.-D. conducted the needs-based study for the system, defined the user requirements for the system, and designed most of the user interfaces; S.H. developed the system with advice from W.Z. W.Z. wrote the paper based on the master’s thesis of S.H. M.F.T. and P.A.S.-D. extensively edited the paper.

Funding

This research was funded by Woodruff Foundation.

Acknowledgments

This paper is based on the master’s thesis [23] of the first author who has the copyright. This study is supported in part by a grant from the Woodruff Foundation and by an FRD-Internet of Things award from Cleveland State University. The authors received no funding to publish open-access.

Conflicts of Interest

The authors declare no conflict of interest. The funding sponsors had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, and in the decision to publish the results.

Abbreviations

The following abbreviations are used in this manuscript:
LAMPLinux operating system, Apache Web server, MySQL database, and scripting languages Perl, PHP,
and Python
CSSCascading Style Sheets
SMTPSimple Mail Transfer Protocol
UIUser Interface
GUIGraphic User Interface
URLUniform Resource Locator
IDEIntegrated Design Environment
HTTPHyper-Text Transfer Protocol

Appendix A. Implemented Web Pages and Use Cases

Appendix A.1. Homepage

The DrugHelp.Care web application starts with the homepage shown in Figure A1. It has two main buttons, one for substance users and another for agencies.
Figure A1. The homepage of the DrugHelp.Care web application.
Figure A1. The homepage of the DrugHelp.Care web application.
Asi 01 00047 g0a1

Appendix A.2. Searching for Service

Figure A2 shows a sequence of screenshots for doing a search. After clicking the “Search Treatment Services” button on the homepage, one can see the search page where a user can choose one or more particular service he or she is looking for. Once the search filter is selected, the user would click the “Next” button to see the search result, which contains the list of agencies that provide the selected services if one is found. A user would then select a particular facility and click the “Next” button to see the details, which contains the information such as the availability, whether there is an available slot, and the estimated wait time if there is no available slot. The final search result page also facilitates the user to call the facility directly by clicking the “Call” button, or to view the institution’s website, or to check the map of the facility.
Figure A2. The sequence of steps for search for a service.
Figure A2. The sequence of steps for search for a service.
Asi 01 00047 g0a2
As we can see in all these pages, the space is intelligently managed by using Accordion and collapsible cards and all the important buttons such as call, web and map are highlighted and placed on top.

Appendix A.3. Treatment Facility Account Sign-Up

Figure A3 shows a sequence of screenshots for account sign-up. To sign up, the administrator clicks the “Manage Agency Account” button on the homepage, which will bring up the account sign-up page in which the person is expected to enter information such as agency name, agency website, mailing address, phone number, email address and the password. Once the information is entered, the person can click the “Save & Continue” button to save the information. This action will trigger an automated email sent to the administrator for verification. This email contains a unique link for the person to click. Upon clicking the link, the person will see a web page containing a special checkbox, which ensures that the verification operation is being done by a human instead of a software bot.
Figure A3. The sequence of steps for an agency to sign up with our web application.
Figure A3. The sequence of steps for an agency to sign up with our web application.
Asi 01 00047 g0a3

Appendix A.4. Agency Sign-in and Password Reset

Figure A4 shows the agency sign-in page, the reset password page, and the automatically generated email containing a link to reset the password. The sign-in page on the left includes a special checkbox, which ensures that the operation is being done by a human but not a software bot. The password is masked by bullets for privacy while the user is typing it.
If the user forgets the password by any chance, the person can the click the link provided on the sign-in page to reset the password, as shown in the middle figure in Figure A4. An automatically generated email will be then sent to the user’s email account, as shown in the rightmost figure in Figure A4 . This email contains a link for the user to reset the password.
Figure A4. From left to right, the agency sign-in page, the reset password page, and the automatically generated email containing a link to reset the password.
Figure A4. From left to right, the agency sign-in page, the reset password page, and the automatically generated email containing a link to reset the password.
Asi 01 00047 g0a4

Appendix A.5. Agency Dashboard

Figure A5 provides the dashboard and example pages for the operations supported by the dashboard: (a) The agency’s dashboard; (b) The service registration page; (c) The service offering registration page; (d) The page that shows all the registered services with a data completion progress indicator for each of the services; (e) The page to update a registered service; (f) The page to select the insurance plans accepted for a registered service.

Appendix A.6. Periodic Update on Service Availability

Figure A6 shows an example email reminder and the pages to manage service availability and the waitlists. The reminder email contains a link for the administrator to visit the update page to enter the latest availability and waitlist information.
Figure A5. The dashboard and example pages for the operations supported by the dashboard: (a) The agency’s dashboard; (b) The service registration page where the administrator can select one or more services and sub-services and continue with the registration; (c) The service offering registration page where the administrator can add one or more offerings for each service based on time or location; (d) The page that shows all the registered services with a data completion progress indicator for each of the services; (e) The page to enable the administrator to update a registered service; (f) The page where the administrator can select the insurance plans accepted for a registered service.
Figure A5. The dashboard and example pages for the operations supported by the dashboard: (a) The agency’s dashboard; (b) The service registration page where the administrator can select one or more services and sub-services and continue with the registration; (c) The service offering registration page where the administrator can add one or more offerings for each service based on time or location; (d) The page that shows all the registered services with a data completion progress indicator for each of the services; (e) The page to enable the administrator to update a registered service; (f) The page where the administrator can select the insurance plans accepted for a registered service.
Asi 01 00047 g0a5
Figure A6. The reminder email, the manage availability page, and the manage waitlist page.
Figure A6. The reminder email, the manage availability page, and the manage waitlist page.
Asi 01 00047 g0a6

References

  1. NIDA. Overdose Depth Rates. Available online: https://www.drugabuse.gov/related-topics/trends-statistics/overdose-death-rates (accessed on 1 September 2018).
  2. Beletsky, L.; Rich, J.D.; Walley, A.Y. Prevention of fatal opioid overdose. JAMA 2012, 308, 1863–1864. [Google Scholar] [CrossRef] [PubMed]
  3. Brucker, D. Exploring the relationship between access and retention among substance abuse treatment admissions. J. Drug Issues 2010, 40, 553–576. [Google Scholar] [CrossRef]
  4. Andrews, C.M.; Shin, H.C.; Marsh, J.C.; Cao, D. Client and program characteristics associated with wait time to substance abuse treatment entry. Am. J. Drug Alcohol Abuse 2013, 39, 61–68. [Google Scholar] [CrossRef] [PubMed]
  5. Friedmann, P.D.; Lemon, S.C.; Stein, M.D.; D’aunno, T.A. Accessibility of addiction treatment: Results from a national survey of outpatient substance abuse treatment organizations. Health Serv. Res. 2003, 38, 887–903. [Google Scholar] [CrossRef] [PubMed]
  6. Albrecht, J.; Lindsay, B.; Terplan, M. Effect of waiting time on substance abuse treatment completion in pregnant women. J. Subst. Abuse Treat. 2011, 41, 71–77. [Google Scholar] [CrossRef] [PubMed]
  7. Prochaska, J.O.; DiClemente, C.C.; Norcross, J.C. In search of how people change: Applications to addictive behaviors. Am. Psychol. 1992, 47, 1102. [Google Scholar] [CrossRef] [PubMed]
  8. Enos, G. Agency’s reduction in wait times opens opportunity in court system. Alcohol. Drug Abuse Wkly. 2010, 22, 1–7. [Google Scholar]
  9. Leshner, A.I. Science-based views of drug addiction and its treatment. JAMA 1999, 282, 1314–1316. [Google Scholar] [CrossRef] [PubMed]
  10. Guerrero, E.G. Enhancing access and retention in substance abuse treatment: the role of Medicaid payment acceptance and cultural competence. Drug Alcohol Depend. 2013, 132, 555–561. [Google Scholar] [CrossRef] [PubMed]
  11. Harding, K.E.; Robertson, N.; Snowdon, D.A.; Watts, J.J.; Karimi, L.; O’Reilly, M.; Kotis, M.; Taylor, N.F. Are wait lists inevitable in subacute ambulatory and community health services? A qualitative analysis. Aust. Health Rev. 2018, 42, 93–99. [Google Scholar] [CrossRef] [PubMed]
  12. Hoffman, K.A.; Quanbeck, A.; Ford, J.H.; Wrede, F.; Wright, D.; Lambert-Wacey, D.; Chvojka, P.; Hanchett, A.; McCarty, D. Improving substance abuse data systems to measure ‘waiting time to treatment’: Lessons learned from a quality improvement initiative. Health Inform. J. 2011, 17, 256–265. [Google Scholar] [CrossRef] [PubMed]
  13. Carr, C.J.; Xu, J.; Redko, C.; Lane, D.T.; Rapp, R.C.; Goris, J.; Carlson, R.G. Individual and system influences on waiting time for substance abuse treatment. J. Subst. Abuse Treat. 2008, 34, 192–201. [Google Scholar] [CrossRef] [PubMed]
  14. Zhao, W.; Luo, X.; Qiu, T. Smart Healthcare. Appl. Sci. 2017, 7, 1176. [Google Scholar] [CrossRef]
  15. Ickin, S.; Petersen, K.; Gonzalez-Huerta, J. Why Do Users Install and Delete Apps? A Survey Study; International Conference of Software Business; Springer: Cham, Switzerland, 2017; pp. 186–191. [Google Scholar]
  16. Lawton, G. LAMP lights enterprise development efforts. Computer 2005, 35, 18–20. [Google Scholar] [CrossRef]
  17. Wilson, L. Emerald Jenny Foundation Helps Addicts, Families Connect with Nearby Resources. Available online: https://www.news5cleveland.com/news/e-team/emerald-jenny-foundation-helps-addicts-families-\connect-with-nearby-resources (accessed on 1 September 2018).
  18. Bootstrap. Introduction to Bootstrap. Available online: https://getbootstrap.com/docs/4.0/getting-started/introduction/ (accessed on 1 September 2018).
  19. Baltimora. Basic Concepts of Flexbox. Available online: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible\_Box_Layout/Basic_Concepts_of_Flexbox (accessed on 1 September 2018).
  20. Luo, X.; Sun, J.; Wang, L.; Wang, W.; Zhao, W.; Wu, J.; Wang, J.H.; Zhang, Z. Short-term wind speed forecasting via stacked extreme learning machine with generalized correntropy. IEEE Trans. Ind. Inform. 2018, 14, 4963–4971. [Google Scholar] [CrossRef]
  21. Luo, X.; He, Z.; Zhao, Z.; Wang, L.; Wang, W.; Ning, H.; Wang, J.H.; Zhao, W.; Zhang, J. Resource Allocation in the Cognitive Radio Network-Aided Internet of Things for the Cyber-Physical-Social System: An Efficient Jaya Algorithm. Sensors 2018, 18, 3649. [Google Scholar] [CrossRef] [PubMed]
  22. Luo, X.; Xu, Y.; Wang, W.; Yuan, M.; Ban, X.; Zhu, Y.; Zhao, W. Towards enhancing stacked extreme learning machine with sparse autoencoder by correntropy. J. Frankl. Inst. 2018, 355, 1945–1966. [Google Scholar] [CrossRef]
  23. Hiriyanna, S. DrugHelp.Care—A Web Application for the Discovery of Drug Addiction Treatment Facilities. Master’s Thesis, Cleveland State University, Cleveland, OH, USA, 2018. [Google Scholar]
Figure 1. Major components of the DrugHelp.Care web application.
Figure 1. Major components of the DrugHelp.Care web application.
Asi 01 00047 g001
Figure 2. The main user story for the DrugHelp.Care web application.
Figure 2. The main user story for the DrugHelp.Care web application.
Asi 01 00047 g002
Figure 3. An example display of collapsible items using Accordion.
Figure 3. An example display of collapsible items using Accordion.
Asi 01 00047 g003
Figure 4. Tables used in the database and the relationship model of the database.
Figure 4. Tables used in the database and the relationship model of the database.
Asi 01 00047 g004

Share and Cite

MDPI and ACS Style

Hiriyanna, S.; Tedor, M.F.; Stoddard-Dare, P.A.; Zhao, W. Design and Development of a Web Application for Matching Drug Addiction Treatment Services with Substance Users. Appl. Syst. Innov. 2018, 1, 47. https://doi.org/10.3390/asi1040047

AMA Style

Hiriyanna S, Tedor MF, Stoddard-Dare PA, Zhao W. Design and Development of a Web Application for Matching Drug Addiction Treatment Services with Substance Users. Applied System Innovation. 2018; 1(4):47. https://doi.org/10.3390/asi1040047

Chicago/Turabian Style

Hiriyanna, Sachin, Miyuki F. Tedor, Patricia A. Stoddard-Dare, and Wenbing Zhao. 2018. "Design and Development of a Web Application for Matching Drug Addiction Treatment Services with Substance Users" Applied System Innovation 1, no. 4: 47. https://doi.org/10.3390/asi1040047

Article Metrics

Back to TopTop