Claims Dashboard: Putting it Together


Insurance Claims Dashboard Case Study
Case Study Scenario
3m 55s
Start course

This course takes you through a case study of a real-world scenario in a financial setting. We'll go through how data gets processed, stored, and presented for an insurance dashboard. This dashboard displays all different types of insurance and is powered by an underlying database. So over this course, you'll both see some specifics for the industry vertical of insurance and some specifics on how to process data.

This course is a little less technical than some of our other database-related content, so if you don't have Python or SQL skills, that's fine. This course is really ideal for those who want to learn a little bit more about how all of the pieces go together to understand more of where to dive in deeper.

If you have any feedback relating to this course, please let us know at

Learning Objectives

  • Learn how to put together a data processing solution for an insurance company
  • Plan the project
  • Build the front-end interface, the back-end database, and the middleware that connects the two
  • Put the whole dashboard solution together

Intended Audience

  • Data engineers and database administrators
  • Anyone who wants to gain insights into how a data-handling solution is built in a real-world environment.


To get the most out of this course, you should have some basic experience with databases and building IT solutions.


So now we're gonna go back to our architectural diagram, but you'll see here that we've actually filled in some of the specific technologies that we've chosen for our claims dashboard. So starting with the front-end user interface, we've decided to go with the Web UI that will be written in a combination of HTML, CSS and JavaScript. And then that front end makes requests out to the API, which is our middleware, which we've decided is gonna be a REST API. And we're going to write that in Python using the flask library. And then our API is going to connect our front end to our back end, which we've decided is gonna be a standard relational database. And remember, this is where we have our policy and our claims table that we designed and this relational database is going to be postgres. And finally, we've added an additional piece, which is our four primary data sources, which are claims and policy raw databases, which are going to be fed into our back-end postgres database using Apache NiFi. 

It's important to remember that this is just one example. And while we've discussed specific technologies that would work for our Acme claims dashboard example, these are not the only technologies that would work for your organization. You might choose different technologies because something might just work better for you. Or you may have a technology in-house that's preferred. So, for example, you might prefer to write your REST API in Node JS, either because that's your preferred technology solution, or maybe that's just what your API developers know. So use this as a roadmap and a prototype, but not necessarily the be all and end all that you have to do a similar BI dashboard tool in exactly the same way that we discussed it in this course. 

So finally the moment of truth has arrived. We're going to take our finished product, or at least the first version of the finished product, and go back to the Acme claims team, and we're going to show it to them. And hopefully, if we followed the development plan that we came up with all the way back in the planning stage, we're gonna have something that's very close to, if not exactly, what they want. And the good news is, hopefully we've made our claims team very happy. The bad news is what often happens is when you do a good job in these sorts of projects, people want to keep adding more onto the product, so this does tend to be a bit of an iterative cyclical process. You do need to be a little bit aware of scope creep because of that, but in general it's a really good sign when users say this is really wonderful, can we expand it? Can we do this and that and another thing?  That means you've done your job well and you've built a good product that's useful for your users. 

So that's our case study in a nutshell. I hope that everyone listening to this course got a bit out of it, and I know this was a bit of a quick hit, but hopefully it gives you a good overview of how you would design a BI dashboard and hopefully the real-world insurance example, bringing it back to what you would do for the Acme Claims Department, helped to make this process more concrete. Thank you so much for your time and attention, and now I turn it back over to Chris to wrap things up.


Introduction - Case Study Scenario - Planning - Building the Database - Front-End Design - Middleware Design

About the Author
Learning Paths

Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity.  With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing  decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.