Building Ana the insurance chatbot: Part 2 of 3 – Behind the scenes

Share this post:

This post is the second in a series taking a deeper look at the design and implementation of a cloud based Chatbot, built using Watson Conversation and IBM Cloud. To be familiar with the contents of this post, it is strongly recommended to read the first post in this series, “Getting Started with Watson Conversation and IBM Cloud”, here.

In this post, I’ll concentrate on the data model and the implementation of the cloud/server- based components (you can try the app here). Just note that you’ll need to make a local account, so that it’s personalized—it’s quick to do.

Data model

Each new ‘useful’ app concept that I build convinces me of the importance of relating the design intentions, user interface and even the conversation to a data model.

Ana uses a fairly simple model. Each personal account has a benefit object and each benefit object has a collection of policies (dental, medical, vision etc.). Each policy has a collection of claims against it.

This provides the foundation for policy interactions. Each time you query or file a claim on Ana, it’s referencing this data model.

For this project I started using Mongo from Compose with Node and decided to work with an Object Relational Wrapper for Mongo, called ‘Mongoose.’

I won’t dig deep into the details of how to work with Mongoose here, because their own documentation is pretty wonderful for getting started, but I will write a little more about Ana’s data model.

Mongoose steers you to define schemas for your data model. They’re still stored as json data in a Mongo database. Mongoose maps that for you, yet structures an elegant discipline and scaffolds a relationship between the JSON objects.

I find it really helps me to build a mental model of what I’m working with and the beautiful part is that it simplifies the control of reading and saving in the database.

For each of the entities in the diagram above, there’s a single Javascript file that describes the mongoose scheme. You can look at them in this folder here.

If you take a look at the createPolicies function in Passport.js, you’ll see how we build up a person’s ‘healthPolicy’ data, culminating in a call of, which simply saves it in the database.

Similarly, in app.js when we’re reading claim history, you can see a call: ‘Benefits.findOne()’ for a person’s email. That returns their benefits data in json form and allows us to simply iterate through all the policies to read the claim history.

You can also see in app.js where we relate the Mongoose package to the Compose Mongo URL.

I really value the simple approach to modeling and working with data that Mongoose provides. This combination of Mongo/Compose, Node and Mongoose has made me the happiest I’ve ever been in my cloud development work. The Compose service is impressively fast—it feels like data access is almost instant, and always available. If you refresh the page, it draws immediately. To me it’s amazing to think that it’s reading data records from a database, and building a json response, and dynamically building the page on the client in less than a second.

Mongo, Node and Passport

This project began as just a basic JS starter application template from IBM Cloud. Pretty much all of my node apps start there—I create a new JS app on Cloud, download the corresponding starter code and develop steadily locally, using the Cloud Foundry command line to push to the cloud when I change something.

I’m not a fan of frameworks on the client side; I try hard to keep grounded in ‘Vanilla JS.’ On the server side though, there are some Node modules that I’ve become fond of.

I added local authentication to the project using Passport.js. They’ve abstracted the common work needed to create and maintain user sessions. It even encrypts the password in the database.

I started from a basic default template from the Passport site, but you can see how I ended up implementing things in Passport.js where I integrated with Mongo.

It took me a bit of trying to figure Passport out at first, but I’ve used it in other projects since understanding it, and would easily recommend it. As I mentioned earlier, I’m using the Mongoose wrapper around the Mongo database.

And of course, I’m using the Watson Developer Cloud library for Javascript/Node for Watson Conversation.

You can check it all out in ana.js

Here’s a sequence diagram showing the flow of control:

From the sequence chart you can see that input is messaged to the Watson Conversation API. Depending on the response the conversation API decides on, the code may need to access the Mongo database to fill in some personal data. You can see more of that decision making in the bot.js file.

Take a look at the buildContextObject() function. You can see how the database/policy integration happens with the chat and context object too.

Watch for part 3 of the series, where I write about design thinking and the front-end design and development approaches used in making this chatbot.

Learn more about Watson Conversation
Build your own chatbot with Watson

Some other useful links:

Watson Conversation Developer Resources
IBM Bot Asset Exchange
Improve Your Chatbot Using Watson Conversation Chat Logs

See also:

Building Ana the insurance chatbot: Part 1 of 3 – Getting starting with Watson Conversation and IBM Cloud

Building Ana the insurance chatbot: Part 3 of 3 – Front end and UX design


Digital Designer & Developer | IBM Bluemix

More InsurTech stories

To energize innovation in financial services, take it outside

Financial companies have always been innovators. But in this age of digital transformation, innovation in financial services is more important than ever to stay competitive. Innovation processes, traditionally limited to product development, are now spreading throughout the entire organization. Many companies, however, are not yet well-positioned to reap the benefits. When researchers from the IESE […]

Continue reading

Four ways to stem the growth of financial crime in insurance

Insurers have long understood that the ability to quickly detect fraudulent claims not only stems losses, but also minimizes the impact to legitimate customers as well. But as more complex financial crimes like money laundering, employee fraud, and corruption have gravitated toward insurers more recently, many don’t have the programs in place to combat these […]

Continue reading

How can insurers stay relevant when insurance ceases to be mandatory?

Insurance and insurers have been around for millennia, with modern insurance starting in the U.K. more than 300 years ago. For much of this time, incumbent insurers have been protected from competition by four big barriers: regulation, the law of large numbers, the trust nature of insurance, and, last but not least, the inertia of […]

Continue reading