Complex interaction: multi-audience, multi-channel, 1:M

Overview

In this topic, we apply a few different concepts into a single interaction workflow, illustrating the use of multiple audience definitions to support a specific multi-channel use case. The use case illustrates how to communicate to each channel at different resolutions within the data model, which requires multiple audience definitions. In addition, we use a table asset within the email communication, which requires a one-to-many (1:M) relationship between the resolution and the data to be displayed in the table asset.

Use case

A healthcare payer or healthcare provider wants to send a list of active prescriptions to another system, and that requires an extract of the prescriptions as well as other information related to the prescription. In addition, they want to send an email to the head of household with a list of all of the active prescriptions for the household.

Compliance Warning:

Make sure that you have documented authorization on file in your database for the Head of Household (HoH) to view each household member’s prescription data. This authorization field must be used in your selection rules to confirm that only authorized prescriptions are included. You are responsible for managing all applicable compliance requirements (e.g., HIPAA) in your campaign criteria.

Although this use case could be handled using multiple workflows, this topic illustrates how to do this using a single workflow.

Requirements

Below are some requirements to be able to make this work:

• A properly configured data model

• Multiple resolutions and audience definitions

Data model

To support this use case, we need a data model that resembles the one below. This Entity Relationship Diagram (ERD) consists of three different tables: Person, Household, and Prescription:

RPI configuration

The RPI configuration outlined in this section aligns to the data model that is defined to support this use case.

Database keys

Create a database key for the Household and the Prescription tables.

• Household_ID

• Prescription_ID

Resolutions

This configuration will require two different resolutions in order to support this use case. Create a resolution on the Household and Prescription tables.

• Household Resolution

  • Database Table: Household

  • Database Key: Household_ID

• Prescription Resolution

  • Database Table: Prescription

  • Database Key: Prescription_ID

Audience definitions

This use case requires two audience definitions to align with the two resolutions: one for the Household and another for the Prescription. When you configure each of the audience definitions, Household_ID should be included in the fields that are written to offer history for both tables along with any other database keys that are found in the table.

Example offer history definition for audience definition

Joins

You will need to establish two simple joins: from the Household table to Prescription, and from the Household table to Person. Prescription will be used to configure the table asset from the Household table, and it requires a one-to-many (1:M) relationship to be able to generate a table that will have more than one prescription for the table asset.

• Household table to Prescription table on Household_ID - 1:M

  • The list of Prescriptions for households.

• Household table to Person table on Individual_ID - 1:1

  • This join links to the email address for the individual so that you can send the email with the list of prescriptions.

  • This is illustrated as a 1:1, but it could be a M:1 as well where there would be multiple households that would link back to a single person. This would be the case for a person who is associated to more than 1 house. This is possible, but not the way this use case is being illustrated.

• Person table to Prescription table on Individual_ID - 1:M

  • This allows for individuals to be linked to specific prescriptions. In this particular example, this join is not required, but is expected to be configured for other uses and would be a common join in this type of a data model.

Interaction (campaign) configuration

This section reviews the campaign configuration required to meet this use case.

High-level steps

1. Create selection rules

2. Create audiences

3. Create an extract

4. Create an email offer

   1. Create a Table Asset

5. Create an interaction

1. Create selection rules

You need to create two selection rules: one at each resolution level.

Prescription resolution

Create a selection rule that identifies the prescriptions that you want to extract and send emails about. In this example, we are just selecting prescriptions with a status of “Active”. The criteria can be as specific as your use case requires, and the outcome will be the same.

Household resolution

Create a simple selection rule at the household level that will select all households. The reason we can do this is that when we use this rule in the Interaction, it will be a part of a batch audience that is downstream from the prescription batch audience. So, it will include the records from the prescription batch audience as a part of the selection criteria based on the interaction configuration, which will only select households that have prescriptions identified by the previous selection rule.

In addition to this rule, you should ensure that the email for the individual that is identified as the head of the household has an email address in the database and is actively opted in to receive email communications. This is not illustrated in this example, but is applicable and should be done in a production execution of a campaign of this nature.

2. Create audiences

Now that you have the selection rules created, you can configure two audiences associated to the selection rules. One rule will be used for each of the audience definitions required for this use case.

Prescription audience

The prescription audience will use the prescription audience definition and the prescription selection rule that was created in the previous step.

Household audience

The household audience will use the head of household audience definition and the household selection rule that was created in the previous step.

3. Create an extract

Create an export template that will be used to export all active prescriptions and associated attributes required to be extracted for the use case.

Extract options

Extract attributes

The table name that contains Personally Identifiable Information (PII), like email address, is named INDIVIDUAL_GOLDEN_RECORD in the extract screenshot below, but it would be equivalent to the Person table in the ERD above. Also Prescription_Household is equivalent to Prescription in the ERD above.

4. Create an email offer

Next you want to create an email offer that has some general information and includes a table of all of the active prescriptions for the individual's household.

Create a table asset

Create a table asset how you see fit, including the columns and configuration that you need. The important part is that you include the filter criteria that was used in the original selection criteria in the initial prescription audience to ensure that you only get those prescriptions when the table is constructed from the prescription data for the household.

Create HTML content for the offer

Now you can create the HTML asset for the email offer with the table asset as a part of the content. The content is personalized with the full name from the Person table and the table asset, which will include all active emails.

Create an email offer

Now you can create an email offer and use the HTML and associated table asset to configure the offer. You could have just entered the HTML and table asset within the offer, but by using an HTML asset, you allow for reusability of that content in other offer assets.

5. Create an interaction

Now you can create an interaction that extracts all prescription records and then it sends an email to the head of household with a table of all of the active prescriptions in it.

• The first batch audience will be configured with the active prescription audience.

• The second batch will be configured with the household audience so that we change dimensions to the head of household to be able to send a single email per household.

Sample email with table asset

This is an illustration of each of the pieces of the email in order to show the final result of the email that would be sent to the head of household. The first few illustrations below are similar to the ones above shown in the section for configuring the offer.

HTML asset

Here is an example of the HTML in RPI using the table asset to be used in the offer:

Email offer

Here is the offer that is using the HTML asset:

Example email received

Here is a sample of the email received for this offer, which includes three different patients in the same household.

Considerations

Given the data structure and that the head of household will be the only record that has a link back to the Person table, you will only be able to include personalization fields from the Person table for the head of household.

If you want to include additional personalization attributes, from the Person table, for each prescription in the table asset, you will need to include those fields on the Prescription table. The reason is that the table asset requires the one to many relationship of household to prescription to generate the table asset properly. So this may require that you denormalize some of the data in the data model in order to support the use case requirements. For example, if you wanted to include the first name for the patient/individual associated with each prescription in the table, then you would need to include the first name on the Prescription table.

Alternatively, you could duplicate the Person table, assign it a slightly different name, and then you could join to that table from Household using a multi-join and go through the Prescription table. This will allow for additional person fields to be included in the table asset. A view of the Person table may be a simple way to support this approach, but you need to be aware that there may be performance implications of a view, depending on the database technology that is being used, that may make de-normalizing the fields onto the Prescription table a better option.

Alternative data model for additional table asset personalization

Here is an example ERD to support additional table asset personalization with attributes from the person table: