A Simple, Flexible and Scalable Approach for Generating Tailored Questionnaires and Health Education Messages

Abstract

Tailored health information is important for generating patient-specific recommendations in clinical decision support systems and for crafting health education materials that are specifically customized to a patient. Many previous attempts to generate tailored information require complex representations, lack general applicability, and are inflexible to content alterations. In this article, we describe a simple, yet flexible approach for tailoring health communication. This generalized and scalable approach relies on a flexible state representation of each individual and an expandable rule drafting and processing engine. It utilizes a relational database schema and a simple table structure to maintain each individual's past and current health information. Content for tailored communication is represented in a single table which stores predefined logic describing the rules for selecting content applicable to specific individuals. The flexibility, scalability, and simplicity of this approach are demonstrated by describing two diverse projects. One project has provided patient-tailored decision support for physicians for over 82,000 patient encounters and the other generates tailored health questions and messages for patients through a tool developed in less than 4 months.

The ability to adapt health-related communications to the attributes of individual patients is fundamental for generating patient-specific clinical decision support, as well as for enhancing the effectiveness of health education materials through tailored messages.^1-5 There have been many successful approaches to guideline representation (for physician decision support) and to the customization of health-related communications.^6-15 These approaches, although powerful in their representation of very involved algorithms, are often complex to implement and, therefore, difficult to use for new applications. In contrast to these other efforts, we have devised a generalized, scalable, and simple approach for physician decision support and for tailoring health-related communications. Our approach is different in that it creates a state-based representation of a patient's health conditions and generates information based on that patient state. This approach supports content alterations at the table level and is relatively simple to implement.

In this article, we describe the representation model and then demonstrate how this approach has been used in two diverse implementations: one for decision support for physicians and one for tailored health messages for patients.

METHODS

Definitions

In this article, we will first focus on the general constructs of our approach. We use two general terms to describe our design. The term “prompt” indicates a piece of information pertaining to a single concept; this piece of information can take the form of a question, an education message, or a single guideline recommendation. The set of prompts which are generated to create a tailored document (eg, patient encounter form or a health education booklet) will be referred to as the tailored communication.

System Design Goals

As an underlying design principle, we sought to create a general tool that could process diverse content, adapt to a variety of situations, and allow users without informatics training to add, delete, and alter content without requiring additional programming or recompiling of the systems.

To fulfill these goals, we created a simple state representation to contain parameters that collectively describe both the current and previous health states for the individual. We paired each prompt with a conditional statement that defines the conditions which must be met in order to include the prompt in a tailored communication for a specific individual. This conditional statement is constructed out of a predefined set of key words and logic constructs (referred to as the grammar) which describe all of the possible conditions encountered in the problem space addressed by a specific application. Once the grammar is determined, the specific conditions for activating each prompt are specified in a field in a table in the database, hence can be modified without requiring the system to be recompiled. The details for employing these techniques are described in the Results section below.

RESULTS

Model Architecture Overview

Figure 1 illustrates the data flow and architecture of the components of our approach. A trigger event occurs that causes the system to evaluate which prompts are appropriate for inclusion in an individual's tailored communication (step 1). In steps 2 and 3, the system evaluates the current and past health state of the individual and then traverses each prompt to determine if the prompt is relevant for the specific individual. Once the appropriate individual specific prompts have been selected, this group of prompts is saved in the history table (step 4) and the tailored communication is created (step 5). If the prompts are questions that require a response, the data are entered back into the system by either direct manual data entry or by scanned electronic forms (step 6). This process of data entry (step 7) updates both the historical table and the state representation for the individual (step 8). In the sections that follow, each of the components in Figure 1 are described in greater detail.

FIGURE 1.

System components and flow.

Trigger Event

The trigger events are simply the initiating factors that cause the system to evaluate the relevant prompts for a given individual, such as the individual presenting in the clinical setting or otherwise needing a tailored communication. These events are application-specific.

State Table

All aspects of an individual's health state are represented in a single table, referred to as the state table (Table 1). This table contains the set of parameters that defines the current state for each individual in the system. The table is indexed by the subject ID, the date the state was set, and the name of the state.

Table 1.

State Table

Field Name	Description of Field
ID*	Individual's unique ID
Date*	Date state was set
State Name*	Name of the state
State Value	Value of the state

^*Indicates key field.

The selection of specific prompts relies on the prompt table (Table 2) to pair a logical expression with its corresponding prompt text and graphic. Each record in the prompt table is evaluated to see whether it is applicable for the patient's tailored communication.

Table 2.

Prompt Table

Field Name	Description of Field
PID*	Prompt unique ID
Priority Priority	Priority of prompt—dictates order to present prompt
Prompt Text	Text with inserted tailored values. Format of insert is: <StateName>. Most current value for StateName is inserted.
Prompt Graphic	Graphic for fixed body portion of the prompt.
UseGrammar	Formatted logical expression grammar listing conditions upon which to add this prompt. These conditions evaluate the state table for CriticalValues.

^*Indicates key field.

If the logical expression associated with a prompt (from field UseGrammar) is evaluated to be true, the system will add the prompt to the individual's tailored communication. To aid in restricting the size of a tailored communication (preventing it from either being too long or having too many messages), a priority may be assigned to each prompt. This priority, stored in the PromptPriority field, is used to assure the highest priority information is selected first. The printed content of the prompt is split into two fields: (1) the PromptText field contains text-based information into which insertion of data pertaining to the individual (eg, grams of fat in his/her diet) is possible and (2) the PromptGraphic field contains a graphics image which enhances the PromptText, with either an image or appropriately formatted text.

Prompt Processing (Grammar)

The prompt processing engine is the mechanism through which the system determines which prompts should be included in the tailored communication for a specific individual.

In order to represent the conditions under which a prompt should be selected, a logical grammar was created to express the conditionality of each prompt. The minimal set of grammar syntax rules are described below. For most applications, additional grammatical concepts would need to be added, such as greater than, less than, etc.

Format for UseGrammar:

AND_expression [| AND_expression]

One or more

AND_expression

are connected by the logical OR symbol (|).

Format for AND_expression:

StateLookUp [& StateLookUp]

One or more

State Look Up

expression are connected by the logical AND (&).

Format for StateLookUp:

[!] [^]StateName:CriticalValue

By default the individual's most recent value (State-Value) for StateName is queried from the state table and compared to the CriticalValue. If the individual's StateValue for a StateName matches the critical value, the subexpression resolves as true. Some prompt conditions require determining if the StateValue for a StateName has ever been set to a particular Critical-Value. For these queries, we use the symbol “^” in front of the StateLookUp expression. Logical NOT (!) is used to negate the expression. The logic evaluation order is EVER (^), NOT (!), AND (&), OR (|). A small computer program processes each prompt's UseGrammar field expression. The code evaluates the expression against information contained in the state table. If the expression resolves to true, the prompt is added to the individual's tailored communication.

Response Processing

The Response Processing module is used if the tailored communication contains questions that collect data about the individual (eg, tailored questionnaires or clinician prompting systems for which the clinician enters data about an individual). It is the primary engine for automatically modifying an individual's current state by the addition of new data to the state table.

Responses to prompts can be entered into the system either manually or electronically. The individual's state is updated based on the responses associated with prompts. The response table (Table 3) contains the actions to be taken for each possible response. This description of actions defines how the state table should be updated to reflect the new information.

Table 3.

Response Table

Field Name	Description of Field
PID*	Prompt ID
ResponseOrder*	Response order
ResponseType	Type of response
OnResponseSet	State to set in state table on the response

^*Indicates key field.

The field OnResponseSet specifies the entry, if any, to be added to the state table if this response has been selected. The following representation is used, but may be expanded for a specific problem space.

Format for OnResponseSet:

StateName:[$] ResponseValue

If there is a $ symbol, the StateName is set to a value which the individual entered (eg, NUMCHILDREN: 7). If it is not present, the StateValue for a specific StateName is set to the ResponseValue preset text (eg, SMOKER: Yes).

ResponseOrder is used to specify the arrangement of order responses on the data entry form so that the responses can be correctly mapped back to a specific response in the database. ResponseType is necessary for collecting the responses upon data entry.

History Table

The history table maintains an historical record of prompts generated for each individual in the system. This historical record of actual prompts and responses is sometimes necessary for evaluation purposes. This table can also serve to recreate past tailored communications, either for reprinting or for the automated generation of the individual specific data entry forms.

Sample Applications

The first system in which we used this approach was the Child Health Improvement Program (CHIP),^16-18 a physician prompting system for clinicians that generates customized recommendations for each patient presenting to a pediatrics clinic. This system recommends to the pediatrician preventive care services specifically adapted to the needs of each child. The system tracks immunizations as well as other important health promotion topics, such as smoking cessation and proper car seat use. The CHIP system was used in the University of North Carolina Pediatrics clinic for 9 years and in a private pediatrics clinic for 6 years.

The basic concepts described in this paper evolved from the CHIP project. The CHIP system is triggered by the hospital registration system whenever a pediatrics patient presents for a visit. It then prompts the nursing staff to collect data that are age-appropriate for the patient. Once the nurse has entered these data, the system generates a tailored printout on a scan form, which prompts the pediatrician for preventive care services that the system recognizes are due for the patient during the current visit. The pediatrician then uses this form in his/her dialog with the patient and indicates responses to the recommendations on the form by selecting the appropriate check boxes. Once the visit is completed, the form is electronically scanned back into the CHIP system, updating the health state of the patient. Additionally, the system has the capacity to generate a tailored health education letter for the parent based on the child's health state which summarizes the issues addressed at the most recent visit.

The logic grammar for CHIP was expanded to handle immunization tracking by including additional concepts such as time between shots and conflicts between immunizations.

The CHIP system took one engineer 9 months to create and has been used in over 82,000 encounters to provide customized recommendations for over 18,000 unique patients.

Another more recent application utilizing the approach described in this paper is the Fresh Start project at Duke University.¹⁹ The Fresh Start project evaluates the efficacy of a personally tailored, distance-medicine–based program to promote healthful changes in diet and exercise in breast and prostate cancer survivors in a randomized controlled trial.

In the Fresh Start project, intervention participants receive a workbook and a series of newsletters delivered every 7 weeks which are personally tailored on the type of cancer, cancer coping style, race, age, self-efficacy, stage of readiness, and barriers and/or progress toward goal behavior. The participants receive tailored questionnaires after each newsletter that collects information on the participant's current behaviors and progress towards behavioral goals. Control participants receive nontailored materials covering similar topics.

A baseline telephone interview is used to select participants for the study and to collect data to populate a demographic table and the state table. The system is triggered for an individual based on a preset mailing schedule for both the newsletters and the questionnaires. After each mailing, new parameters are added to the state table to reflect mailings which have been sent. Upon entry of responses to the questionnaires, new parameter entries are made to the state table to reflect the participant's current health status. The basic grammar previously described was used without further expansion for this project for the generation of the questionnaires. In a separate process, data are extracted from the state table and demographic table to send a health status file with data on all participants to a graphic design company for generation of the tailored participant newsletters.

The Fresh Start project took one engineer 4 months to develop and manages information for over 500 study participants.

DISCUSSION

In this article, we have described a simple representation of patient health information that has been used for the generation of patient-specific questionnaires, tailored health education messages for patients, and patient-customized recommendations for clinicians. Traditionally, much of the responsibility for questionnaire development and development of health education content falls on nursing professionals, so the nursing community may find these techniques of value. In addition, nurses are assuming a growing role in patient management which can be facilitated through the types of tailored information systems described in this article.

The representation schema has been implemented in a number of settings over the past 9 years. This representation model takes advantage of the fact that the primary need for tailoring is to capture health state conditions that lead to requests for additional information or the provision of recommendations. In turn, the responses to these messages alter the health state of an individual. Thus, our approach reduces the task of tailoring to (1) evaluating the conditions upon which to generate prompts, (2) generating the prompts, and (3) creating new conditions based upon the responses to the prompts.

In contrast to other knowledge representation approaches, such as the Arden Syntax⁷ or the Guideline Interchange Format (GLIF),⁹ our approach focuses on modeling the state of the individual at a given point in time instead of the logic or context of decision rules. The decision engine for our approach operates by comparing the state of the individual with a state or set of states assigned to a specific action (eg, the conditions under which the action should be performed). If the state of the individual matches the state(s) assigned to the action, the action is carried out (eg, provision of a care recommendation on an encounter form or inclusion of specific content in an educational brochure). In contrast, the decision engines for Arden and GLIF are procedural in that they traverse a series of rules in an algorithm.

Our state-oriented approach may prove challenging for representing clinical practice algorithms which have complex branching, as the database representation renders it less intuitive on how nodes of the clinical algorithm are related. The approach may also be overly daunting if used directly with billing data (such as ICD-9 codes) as capturing all the health codes in a limited grammar set could prove to be overly challenging. However, for many implementations in healthcare, the state representation and state comparison approach described in this article is adequate for the task of tailoring information for providers or patients without the overhead of creating a complex rules processing infrastructure. In addition, as also shown in this paper, the state-oriented approach is scalable to support thousands of records and is flexible to be used in diverse implementations, such as reminder prompts for clinicians and tailored education materials for patients.