How I Built a Patient Registry as a Data Product

Not just a table. A tool for care, accountability, and trust.

Why This Work Mattered

Let me start by saying this: I didn’t build this for data points. I built it for people.

At ARcare, where we serve underserved populations across rural communities, we needed something that could help our care teams see clearly — who was at risk, who was being missed, and where interventions could actually change lives. That meant building a real-time patient registry — not just a database, but a governed, trackable data product that clinical teams could rely on every single day.

What’s a Registry as a Product?

Too often, data teams ship a table and call it a day.

But a true data product has ownership, intent, and usability. It’s built with its audience in mind — with versioning, documentation, access rules, and a feedback loop. It’s something that evolves, not something you duct tape together and pray nobody touches.

So that’s the mindset I took: build this registry like it’s powering lives — because it is.

Step 1: Start with the Pain, Not the Schema

Before I touched Snowflake or wrote a line of DBT, I met with real users:

• Nurse Coordinators who were copying names from spreadsheets just to make outreach calls

• Medical Directors looking at dashboards that told them nothing about appointment patterns

• Analysts running last-minute SQL queries the day of quarterly reporting

And the common thread? Everyone was flying blind — or at best, guessing.

So the first question I asked wasn’t what data we had.It was: "What decisions do you need to make that you can’t right now?"

That’s where the registry began.

Step 2: Architect for Action

Once I had clarity on the "why," I got to work on the "how."

We used a Snowflake-centered stack for stability, security, and scale.

Ingestion Layer

• Azure Data Factory pipelines for batch EMR pulls

• Direct API integration for billing + pharmacy updates

• Change Data Capture for near-real-time vitals and appointments

Warehouse Layer (Snowflake)

• Raw → Staging → Curated schemas

• Unified patient IDs, cross-system deduplication

• Materialized views for real-time filters + snapshotting

DBT Transformation

This is where things came alive:

• Built high_risk_registry with logic for chronic conditions, ER visits, lab gaps

• Designed appointment_no_show_risk using prior behavior + time-of-day patterns

• Created care_gap_summary to highlight missed preventive care by cohort

Every model was tested, versioned, and documented. Period.

Step 3: Respect the Data. Govern It.

Working on healthcare data and the communities we serve, I carry an extra layer of responsibility.

So I made sure our platform honored that responsibility:

• Atlan for PHI classification, tagging, and end-to-end lineage

• Role-Based Access Control (RBAC) and Row-Level Security (RLS)

• Care coordinators saw only their patients. Directors saw their region.

• Every dashboard interaction, export, or query was logged. No guessing, no gaps.

Step 4: Serve the Insights in the Right Format

The best data product is one you don’t need to explain every week. So we embedded our registry directly into tools people already knew:

• Power BI dashboards with drop-down filters by risk score, region, provider

• Exportable CSVs for call lists, follow-up campaigns, and grant compliance

• Python access for our analysts and modelers working on readmission risk

Every delivery method was wrapped in context — definitions, timestamping, version info.Because data without clarity can still do harm.

What Changed?

• Cut manual list-building time from 3 days to under 2 hours

• 80% reduction in ad hoc SQL requests

• Increased adoption of self-serve dashboards by 3x

• Enabled real-time outreach campaigns tied to real risk scores

But more than metrics — I watched a nurse coordinator pull up the registry and say:"This is the first time I feel like I know who needs help — and why."

That stuck with me.

Final Thought

This wasn’t just about getting data from point A to point B.

It was about building a system that respects context, privacy, and people.It was about listening first, designing with purpose, and delivering with care.

And honestly? It was about reminding folks that data work is people work.

Want to See It?

I break down the architecture, tooling, and dashboard examples in this case study.

If you’re building something similar — reach out. Let’s connect and build better, together.