The Road To Data Self Service — Part 2: What Makes the GPS Actually Work?
In my last article, I compared the evolution of healthcare data self-service to the evolution of navigation — from paper atlases to Google Maps. A clinical leader should be able to ask “why did readmissions increase this quarter?” the same way I ask my phone to take me downtown Chicago, and get a clear, trusted answer without needing to know which dataset, which table, or which source system to look in.
But that analogy raises an obvious question. What actually makes Google Maps work? The answer isn’t the screen you see. The real magic is everything underneath it.
When I say “take me to downtown Chicago,” Google Maps has to do a remarkable amount of work before it can show me a single direction. It needs to understand what “Chicago” means, where it is, what roads connect to it, which of those roads are currently open, how they relate to one another, and what traffic looks like right now. Then it needs to know where I am, build the best route, and communicate all of that back to me simply and clearly.
That same set of challenges sits at the heart of data self-service in healthcare.
Building a platform where a clinical or operational leader can ask a plain-language question and get a trusted answer isn’t just a technology problem — it’s an architecture problem. There are six building blocks that make it possible. Think of them as the infrastructure underneath the GPS.
1. Data Foundation — Where Are We Starting From?
Before a GPS can tell you where to go, it needs to know where you are right now.
A data self-service platform works the same way. Before it can answer any question, it needs to know where the data is coming from — EHRs, clinical systems, financial systems, operational systems, and everything in between. Our data foundation brings all of that together into a governed, trusted environment in GCP and BigQuery.
The result: a user doesn’t need to know which source system contains the information they’re looking for. The platform already knows. They simply ask the question.
2. Data Model — How Are the Roads Connected?
Going back to my 2000 road trip for a moment. I knew I-81 was the road I needed. What I didn’t fully appreciate in that moment was how the roads connected. I was supposed to take I-81 North toward Niagara Falls. Instead, somewhere between laughing with my friend and talking about everything under the sun, I took I-81 South. The road itself wasn’t wrong. I-81 was exactly the right highway. I was simply on the wrong side of the intersection.
A good GPS prevents that. It doesn’t just know that I-81 exists. It knows there’s an intersection, that I need the northbound side, and that the direction I choose determines where I’ll eventually end up.
A data model does the same thing for healthcare data.
Knowing that we have patients, encounters, diagnoses, procedures, providers, and facilities is like knowing that I-81, I-80, and I-76 exist. That’s a start. But the real value comes from understanding how they connect.
A patient has an encounter. An encounter occurs at a facility. An encounter has diagnoses. A procedure is performed during an encounter. A provider orders or performs that procedure.
Those connections determine every path we can take through the data. Without them, a user can easily end up on the equivalent of I-81 South — they find a table that looks right, pull a number that seems reasonable, and never realize they’ve been heading in the wrong direction the whole time.
A data model is the road network. Not just what roads exist, but how they connect and where each path leads.
3. Taxonomy — What Kind of Roads Are These?
Knowing that roads exist and how they connect is important. But Google Maps also needs to know what kind of road each one is — interstate versus state route versus local street — and what kind of place each destination is. It knows that one location is a hospital, another is a gas station, another is a school. That classification is what lets it respond sensibly when I search for “hospital near me.”
That’s what taxonomy does for healthcare data — it gives everything a common language and a meaningful category.
An encounter can be classified as emergency, inpatient, or outpatient. A procedure can be grouped as imaging, surgical, or diagnostic. A provider can be classified by role or specialty. These categories let the platform understand what someone is actually asking for, not just match their words to a table name.
So when someone asks for “emergency department encounters,” the system isn’t running a text search. It understands that emergency department encounters belong to a specific category of healthcare encounter, and it knows exactly where to look.
If the data model tells us how the roads connect, taxonomy tells us what the roads, exits, and destinations actually are.
4. Ontology — What Do These Connections Actually Mean?
Google Maps doesn’t just see I-81 as a line on a map with a label. It understands the meaning of the roads and the relationships between them. I-81 North and I-81 South aren’t two versions of the same road. They represent different directions, different destinations, and a fundamentally different journey.
That’s what ontology adds.
If taxonomy says “this is a highway” and the data model says “these highways connect,” ontology goes a step further and says “this road leads toward this destination, and this exit provides access to this particular place.” It gives meaning to the relationships — not just that they exist, but what they represent.
In healthcare, the difference matters enormously. A provider may order a procedure. A different provider may perform it. The procedure may produce a result. That result may be associated with a diagnosis or outcome. Those aren’t the same relationship with different labels — they mean different things and answer different questions.
Get Ganesh Ramaswamy’s stories in your inbox
Join Medium for free to get updates from this writer.
So when someone asks “which physicians ordered the MRI?” the system needs to understand that ordered is different from performed. When someone asks “which patients had an MRI because of a particular diagnosis?” the system needs to understand the relationship between patient, diagnosis, encounter, and procedure.
Taxonomy helps us classify the world. The data model connects the pieces. Ontology tells us what those connections mean.
5. Knowledge Graph — Seeing the Entire Road Network at Once
One of the most powerful things about modern GPS is its ability to see the entire road network as one connected system. It doesn’t look at your street, then your highway, then your exit separately. It sees all of it at once and finds the best path through it.
A knowledge graph does the same for healthcare data.
Individually, each piece of information has value. But when you connect a patient to an encounter, the encounter to a facility, the encounter to its diagnoses, a provider to the encounter, and a procedure to its results — you can begin to see the full journey through the healthcare system.
Instead of simply knowing that a patient was readmitted, you can connect the events surrounding that patient:
Patient → Initial Encounter → Diagnosis → Treatment → Discharge → Follow-up → Readmission
Now you can ask questions that require following those connections:
- “What diagnoses were most common among patients who were readmitted?”
- “Which facilities had higher readmission rates for this patient population?”
- “What factors appear to be contributing to the increase in readmissions?”
The platform isn’t searching for a matching word in a table. It’s navigating a network of relationships — the way GPS navigates a road network.
The data model gives us the roads. Taxonomy tells us what those roads and destinations are. Ontology tells us what the relationships between them mean. The knowledge graph brings all of it together into a network we can actually travel through.
In our stack, this is where Neo4j comes in — taking the static entities in our BigQuery data foundation and rendering them as an interconnected network of nodes and relationships that can be traversed in real time.
6. Semantic Layer — Understanding the Destination
When I tell Google Maps “take me to a hospital near me,” I don’t provide an address, a road number, or a database query. I use plain language, and the platform translates that into everything it needs to find the right place and build the right route.
The semantic layer is the translator between the language healthcare users speak and the language the data platform understands.
Consider a simple question: “What is our readmission rate?”
On the surface, straightforward. Underneath it, not so much. Does readmission mean any return to the hospital? A return within 30 days? Only inpatient returns? Does a same-day visit count? Are certain patient populations excluded?
The underlying data may contain everything needed to answer the question. But without a shared definition of “readmission,” two people asking the same question can walk away with two completely different numbers — both of them confident they’re right.
The semantic layer solves this. It translates a business term like “readmission rate” into the precise data, definitions, calculations, and relationships required to answer it consistently. Every time.
So when a physician, analyst, or executive asks “why did our readmission rate increase this quarter?” — they don’t need to know which BigQuery table contains encounters, how admissions link to discharges, or which formula defines the metric. They ask the question. The platform handles the rest.
The user speaks the language of healthcare. The platform speaks the language of data. The semantic layer is the translator standing between them.
The Road Is Built. Now What?
With these six building blocks in place — data foundation, data model, taxonomy, ontology, knowledge graph, and semantic layer — we have the infrastructure for a healthcare data GPS. One that understands the roads, the connections, the meaning, and ultimately the destination.
But here’s the thing about infrastructure: it’s never complete on its own.
Some of the most valuable knowledge in healthcare doesn’t live in any system. It lives with the people who use the data every day — the definitions that got refined over years, the exceptions that never made it into documentation, the context and hard lessons that analysts carry around in their heads. We often call it tribal knowledge.
The next step is figuring out how to bring that knowledge into the platform — to crowdsource it, validate it, and turn it from something that walks out the door when people leave into something the entire organization can rely on.
That’s where the technology journey starts to become something bigger: a culture transformation.
That’s Part 3.
