For rapid deployment, such as during the current pandemic, chatbots work best when they have a simple and singular goal targeted for a specific user. This should be defined in one sentence (eg, “provide screening and education to the general public,” “educate and guide campus visitors on our current visitor restrictions,” or “triage existing patients to the right resources.”). All other decisions around technical infrastructure, workflows, and language choice will be guided from the driving purpose of the chatbot and the intended user.

After screening, the chatbot will offer the user something based on their screening results (ie, information, a phone number to call, a call back, etc). These are the tools the chatbot uses to achieve its goal. Institutions should clearly define what the chatbot can and cannot offer. The possible options can be thought of in three categories:

User-initiated solutions are easier and faster to implement, can usually be incorporated into existing workflows, and have fewer data governance, legal, and compliance issues since there is no need to exchange Protected Health Information (PHI)/Personally Identifiable Information (PII). However, this type of solution may lead to situations in which a high-risk person still walks into a health care facility because they did not or could not follow through with the recommendations. Provider-initiated solutions allow providers to “close the loop” and can feel more personal. They ensure that facilities can be more proactive in properly addressing high-risk patients, but they require new workflows (and therefore additional staff, or additional work for existing staff), are typically more costly, and carry additional legal and compliance considerations. Finally, this decision can help inform whether you should deploy your chatbot inside or outside your institution's secure IT infrastructure.

The majority of chatbot interactions are a series of question-response dyads, with the user either free typing a response or choosing one from preselected options. Your chatbot should include a standard legal disclaimer and eligibility verification (“Are you a patient of…” or “What state/county/city do you live in?”), if relevant to the goal of the chatbot. In terms of screening for COVID-19, it is critical that institutions use the most up-to-date recommendations from trusted public agencies like the CDC. COVID-19 screening can be broken down into exposure risks, symptoms, comorbidities, and other risk factors (Table 1). Additional questions may be appropriate for your particular situation and what the follow-up to the chatbot interactions is meant to be. Institutions should be prepared to update all questions frequently as the situation develops and new criteria become relevant.

Chatbots are capable of interacting with users in a variety of ways. They can be deployed natively in social media platforms, via text messages, email, and embedded in a web page. Native deployment creates a smoother user experience but requires more work and can be more costly. Deploying the chatbot on the web and redirecting users via links distributed through multiple channels (social media, email, text messages) can be more cost-effective and simpler to manage. You should make this decision based on how you will reach as many of your intended users as possible. You can consider the current utilization rates of various communication services you already offer patients and families to help make this decision. For example, if you have very few patients enrolled in your portal, then that is unlikely to be a good deployment strategy. However, if you use text reminders for appointments and families frequently reply back to confirm, then text message may be a better choice.

For institutions with the right technical expertise, there are several frameworks that can be used to build your own chatbot, at little or no cost. For others, several companies provide low-cost chatbot services that include design, implementation, maintenance, and data reporting. Very importantly, note that if your chatbot collects PHI/PII or is integrated into a hospital information system, it will typically require legal and compliance review, along with information security assessment and (likely) a business associate’s agreement (BAA). A BAA is a contract between a covered entity (a health care provider) and a third party that accesses PHI in order to perform a service for the covered entity and is required to be in compliance with the Health Insurance Portability and Accountability Act (HIPAA) [20]. If your institution has an existing BAA with an information services company like Microsoft, Amazon, or Google, then leveraging their chatbot services may be the most expedient way to deploy a solution.

Implementation is the make-or-break of any digital health project, and chatbots are no different. A valuable exercise is to make process maps and storyboard the experience for both the users and the providers that will interact with the chatbot. This is equally effective in low fidelity (eg, post-it notes, whiteboards) and high fidelity (eg, slide decks, animations) formats. A sample process map can be seen in Figure 1. In this example, the family might receive a link to the chatbot through the web, text, email, or social media, and then engage with the chatbot. The chatbot would administer the screening questions and then triage the patient into a risk category, each with a specific set of actions.

Once you have defined your ideal user experience, you can begin to explore how that chatbot integrates into your IT ecosystem. The exact specifications will be highly dependent on the decisions you made regarding goals, users, actions, and workflows. For example, a chatbot that provides users with informational resources based on their risk stratification, but does not collect any PHI/PII, may not require any data storage or tracking and could be run completely from a cloud-based web service. On the other hand, if you will be collecting PHI/PII, or connecting users to other secure hospital information systems like a patient portal, you will require a secure, HIPAA-compliant environment. Figures 2 and 3 provide two network diagram examples of how this might be set up in your local environment. In Figure 2, we see a straightforward, patient-initiated approach, where the patient interacts with a web-hosted bot that provides the patient with information that they can act on, such as calling a hotline for an appointment or logging into a telehealth portal. By contrast, the chatbot in Figure 3 is located in a secure environment (in this case, behind an institutional firewall), enabling it to collect PHI/PII and integrate into other institutional applications. Staff members can act on the collected data, while the patient is provided with appropriate education and resources.

Chatbots generate a significant amount of data and metadata, including user volumes, timestamps, length of conversations, user responses, and link tracking. Your institution will need to decide which data, if any, you are interested in tracking and analyzing. It may be worthwhile to collect chatbot data even if no PII/PHI is being tracked; modern informatics techniques have been used to track the spread of infectious diseases by analyzing social media posts as well as search engine queries; chatbot interactions might also be a useful source of public health data [23,24].

User testing is critical prior to launch. Identify a small group of individuals who will spend time trying to “break” the tool. The goal of user testing is to discover everything that is wrong with the product you built. Your users should be looking for problems in the text, nonsequiturs in the workflow, broken links, bad phone numbers, typos, etc. This is also an opportunity to verify that your database is collecting information in the way it was designed. Once you have completed several iterative rounds of testing, you are ready for deployment to patients.