Our Tips & Observations Actually Doing Healthcare Data Modeling - Part 1

Maximize the benefits of conceptual data modeling with these call-outs

It’s one thing to read textbooks and documentation on data modeling. They’re filled with incredible detail and illustrations to guide you. These resources are widely available, and serve an incredible purpose. Let’s make one thing clear: I am not THE expert on data modeling. I am a professional data consultant who uses data modeling to communicate the value of data to my clients and their bottom lines.

Over the course of my 7+ year career, I’ve seen data modeling done poorly. Very poorly. Often working through 3,000 line SQL queries sitting within the BI tool (instead of the data warehouse) - as you can imagine this is always a nightmare.

However, I’ve pulled knowledge from some of the most respected data modeling methodologies and frameworks, specifically Ralph Kimball’s famous dimensional modeling. On top of that, I am a member of

Joe Reis’s Practical Data Modeling community and lean on his industry leading expertise to conduct data modeling in the Age of AI.

Rather than walking you through how to conduct data modeling exercises, my goal with this series is to call out “gotchas” and tips for the actual process of building data models with clients and stakeholders in healthcare.

Starting with the conceptual data model phase, let’s dive into 3 of them…

Things to Look For When Conceptually Data Modeling

1. Save time where you can

You’re either starting from scratch (greenfield) or walking into an existing data model and reporting stack (brownfield). The key here is to be aware of how many meetings you’re asking the client for during this phase. Look to pull information from EVERY meeting you’re on to gain necessary business context. Don’t solely rely on the conceptual data model sessions for that.

In a greenfield environment, I’ve typically conducted two conceptual modeling sessions to adequately finish the exercise. The time needed to digest and process the objects and their relationships.

However, the majority of healthcare companies we work with are brownfield. They have legacy reporting already. In these scenarios, take advantage of the meeting(s) key stakeholders walk you through those reports.

We’ve been able to pull more than enough business context from these without a formal conceptual modeling session. Especially if the report represents a critical value chain (a good place to start :) ).

After these meetings, we have what we need to begin the conceptual data model version 1 - saving time from multiple data modeling-specific working sessions.

2. Make assumptions, confirm with stakeholders later

In our experience, assumptions typically pertain to what business objects are called (ie. is a customer of a healthcare company called a customer or a patient?). Furthermore, there’s often many to many relationships between certain objects.

From a practitioner standpoint, it goes without saying to always be on the lookout for these many to many relationships. However, validating if that bridge object is accurate needs to be left to the stakeholder. Have them confirm whether we’re thinking about a certain relationship correctly.

Additionally, the order of business events is a critical consideration as well.

Here are some questions that help this approach with stakeholders:

• Can a patient also be a payor, or is a payor only insurance?

• Does a sales order come before an invoice?

• Is a payment considered a revenue transaction?

  
  

3. Start with the Money Trail (Revenue Cycle)

Healthcare organizations are businesses first, and understanding their revenue cycle will unlock the most important relationships in your conceptual model. Every healthcare entity - whether it's a hospital, clinic, or health plan - has a core process for how they generate revenue, and this process touches nearly every other business object in your model.

In most healthcare settings, this means starting with the patient encounter and following it through to payment collection. This journey typically involves: patient registration, clinical services delivery, charge capture, claims submission, payment posting, and adjustments/write-offs. Each step creates or modifies critical business objects and their relationships.

Why this approach works:

Revenue cycle processes are well-documented because they're heavily regulated and audited. Stakeholders understand these workflows intimately because they directly impact the organization's bottom line. When you map these relationships first, you're building the backbone that everything else connects to.

Questions that help uncover this:

• What triggers the creation of a patient account?

• When does a clinical service become a billable charge?

• How do you handle partial payments or payment plans?

• What's the relationship between a claim and multiple service/product lines?

Once you've mapped the revenue cycle conceptually, you'll find that other business processes (quality reporting, clinical outcomes, operational metrics) become much easier to model because they often reference the same core objects and relationships you've already defined.

Leverage These When Building

So there you have it. Three observations for building a robust conceptual data model in healthcare. Whether you’re starting from greenfield or brownfield, these call-outs provide you with applicable tips to drive real ROI with your stakeholders’ data & information using the conceptual framework in traditional data modeling.

Christian Steinert is the founder of Steinert Analytics, helping healthcare & roofing organizations turn data into actionable insights. Subscribe to Rooftop Insights for weekly perspectives on analytics and business intelligence in these industries.

Feel free to book a call with us here or reach out to Christian on LinkedIn. Thank you!