The Dilemma of the Data Scientist

Exploration Requires Visibility

David Park stared at the Slack message from his senior ML scientist, Shreya Vij.

“Data request #847 came back. They removed the prescription refill timing fields for privacy reasons. That was the feature showing the strongest correlation in our prototype. Back to square one. I’m so tired of this.”

Data request #847. They were up to 847 requests in eighteen months.

David had been Jessica’s first meeting after the emergency session a day ago. She wanted to understand what success looked like from his perspective.

He’d been preparing for days. Because the problem wasn’t just that their models failed. The problem was that his data scientists couldn’t do data science.

The Meeting

“Thanks for making time,” Jessica said, gesturing to the chair across from her desk. “I want to understand exactly what success looks like from your perspective. Not what you think I want to hear. What you actually need.”

David pulled up his laptop. “Can I show you something?”

“Please.”

He turned the screen toward her. “This is our readmission prediction model. Eighteen months of work. This chart shows performance on our synthetic training data.”

Article content “That looks good,” Jessica said.

“It does. Now look at this.” David switched slides. “Same model deployed against actual production data in our staging environment.”

Article content The graphs collapsed. Accuracy dropped 26 points. False positives tripled.

Jessica stared at the screen. “What happened?”

“The synthetic data doesn’t have the patterns that real patient data has. Comorbidity relationships are smoothed out. Medication interaction effects are gone. Temporal sequences showing patient behavior don’t exist. We trained a model to recognize patterns that only exist in the synthetic generator’s algorithm.”

He paused. “And that 34% false positive rate? In production, that means our care coordination team gets 3,400 false alerts per month for every 10,000 admissions. After the first few hundred false alerts, they stop trusting the model entirely. It doesn’t matter if the model is deployed if nobody uses it.”

“So the model becomes organizationally useless,” Jessica said quietly.

“Exactly. This is the third model we’ve built this way. Same result every time.”

Jessica frowned. “Is synthetic data ever useful? Or is it just fundamentally flawed?”

David shook his head. “No, it has legitimate uses. I was talking to Alex Martinez in our Test Data Management team last week. They’re using synthetic data for application testing and it’s working great. They generate test datasets based on specific test cases - edge conditions, boundary values, specific scenarios they need to validate. For testing if an application handles data correctly, synthetic data is perfect. You control exactly what you’re testing.”

He continued. “Alex told me something that made it click. He said: ‘I tell the generator exactly what to create - test case 47 needs a claim with three overlapping coverage periods. I get exactly that. It’s predictable and repeatable, which is exactly what I need for testing.’ But that’s the opposite of what we need in machine learning. In testing, you want controlled, predictable data. In ML, you need the messy, unpredictable patterns from real human behavior. I can’t tell a generator what patterns to create because I don’t know what patterns matter yet. That’s what exploration is for. And you can’t explore patterns that were algorithmically smoothed away.”

Jessica nodded slowly. “So it’s not that synthetic data is bad. It’s that it solves a different problem.”

“Exactly. Alex’s team loves it because they can generate exactly the data shapes they need for testing. But I can’t generate the patterns I need for prediction because discovery happens through exploration of real data, not through specification of test cases.”

The Exploration Problem

“Let me back up,” David said. “Data science starts with exploration. You get a dataset, you explore it. Look at distributions, find correlations, test hypotheses about what might be predictive. That exploration is where you discover the features that matter.”

“Okay.”

“We can’t do that. We don’t get the dataset. We get subsets. Anonymized chunks. Fields removed for privacy. Each subset requires a data access request that takes two to three weeks.”

Jessica was taking notes.

“Last month, Shreya was exploring readmission patterns. She hypothesized that prescription refill timing might be predictive. Early refills suggest anxiety about symptoms. Late refills suggest non-adherence. Both could correlate with readmission risk.”

“That makes sense.”

“It took her three weeks to get prescription data. When it arrived, the refill dates had been removed because they’re considered temporal identifiers that could enable re-identification. She got prescription types and dosages, but no timing information. Her hypothesis was untestable.”

“She submitted another request?”

“Request #782. Asked for relative timing - days between prescription date and refill, with actual dates masked. That request took four weeks because it required custom anonymization logic. When it came back, the relative timing was there but it had been rounded to week-level granularity to prevent pattern-based re-identification.”

“And?”

“Week-level granularity destroys the signal. The difference between refilling three days late versus six days late matters clinically. When you round to weeks, it all becomes noise.”

Jessica wrote something down. “So she couldn’t validate her hypothesis.”

“Worse. She wasted two months trying. That’s two months of skilled data scientist time spent not on data science, but on negotiating with data access processes that are designed to say no.”

The Iteration Speed Problem

David switched slides again. “Here’s what the iteration cycle looks like for my team.”

Current Process:

Day 1: Identify potential feature Day 1: Submit data access request Day 14-21: Wait for security review and data provisioning Day 21: Receive anonymized subset Day 22: Discover critical fields are missing or transformed in ways that destroy utility Day 22: Submit clarification request or new request Day 35-42: Receive updated data Day 42: Begin actual feature engineering

“Six weeks to test one hypothesis,” Jessica said quietly.

“Six weeks if everything goes smoothly. And that’s for one feature. A typical model might have 20 to 40 features. We can’t iterate that slowly and expect to compete.”

“What should it look like?”

“At a company with proper data access? Hours. A data scientist forms a hypothesis in the morning, queries the data, tests it, validates or rejects it by afternoon. Tries five more hypotheses that week. Iterates rapidly until they find what works.”

David pulled up another slide. “I ran the numbers. Our team completes about 8 hypothesis tests per month. Based on conversations with peers at other health insurers, their teams are running 60 to 80 tests per month.”

“They’re moving ten times faster.”

“Ten times faster on exploration. Which means they find the predictive features first. Build better models faster. Deploy to production while we’re still waiting on data request.”

The Fundamental Questions

Jessica leaned back in her chair. “Let me make sure I understand something. Do you actually need the sensitive information itself - the real names, addresses, patient identifiers - unaltered in your machine learning workflows?”

David shook his head immediately. “No. That’s the thing. Machine learning doesn’t learn from literal values. It learns from patterns and behaviors represented as numbers. Sensitive information like names, addresses, Social Security numbers - those are identifiers. They tell you WHO someone is, not HOW they behave.”

“Explain that.”

“Think about what makes information sensitive. It’s usually strings - text values that uniquely identify a person. Patient name ‘John Smith.’ Address ‘123 Main Street.’ That’s personally identifiable information because it defines the person. But for machine learning, that text has zero predictive value for something like readmission risk.”

Jessica was following closely.

“What has predictive value? Behavioral patterns. Medication adherence - does this patient refill prescriptions consistently or erratically? Treatment sequences - do they follow up after emergency visits? Geographic risk factors - does their region correlate with certain health outcomes? Those are numerical patterns. And ML models understand numbers, not the literal string ‘John Smith.’”

“So you don’t need to know who the patient is.”

“Correct. I need to know what patterns their behavior shows. The literal identity is irrelevant for prediction. A patient who refills prescriptions three days late consistently - that pattern matters. Whether their name is John Cena or Tom Brady doesn’t change the predictive value of that refill behavior.”

The Partial Visibility Problem

Jessica made a note. “Okay. So if sensitive identifiers don’t matter for your work, why can’t we just remove those sensitive fields from the dataset when it gets delivered to your development environment? Strip out names, addresses, IDs. Give you everything else.”

David grimaced. “That sounds logical, but there are three problems.”

“Go on.”

“First problem: behavioral data gets mislabeled as sensitive. Remember Sarah’s refill timing example? That field was removed ‘for privacy reasons.’ But refill timing isn’t an identifier - it’s a behavioral pattern. The security team saw ‘date field’ and ’temporal identifier’ and removed it to prevent re-identification risk.”

“But the behavior itself isn’t identifying?”

“Exactly. If I told you ‘a patient refills prescriptions 3-5 days late,’ you have no idea whose prescriptions. The pattern is behavioral. It’s only identifying if you can connect it to a specific person. If patient identity is already masked, the refill timing can stay and I get the same predictive value. I don’t care which person’s refill timing it is.”

Jessica nodded slowly. “So the blanket approach removes things you actually need.”

“Second problem: engineering complexity. Someone has to classify what’s ‘sensitive’ - and that’s subjective and changes over time. Then data engineering has to build and maintain pipelines to remove those fields. Every time we add a new data source or new fields, someone has to review them, classify them, update the pipelines. That’s a high maintenance burden. It slows down feature rollout because every new field needs a security review and pipeline modification before my team can access it.”

“And Lisa’s team would have to maintain all that,” Jessica said.

“Exactly. And they’re already stretched thin. Third problem is partial visibility. It’s like asking someone to diagnose a patient’s condition but only showing them the left half of the X-ray. If fields are removed, my team works within boundaries defined by someone else’s classification of what’s sensitive. We can’t explore patterns in removed fields. We can’t discover that a ‘sensitive’ field actually has predictive value worth exploring. We’re constrained before we even start.”

Jessica frowned. “So you’re working blind.”

“Exactly. And when the model fails, we can’t diagnose why. Is it our feature engineering? Our model architecture? Or is it that the training data is missing patterns that exist in production? We waste weeks debugging problems that might not even be in our control.”

Jessica tapped her pen on her notebook. “So removing fields sounds simple but creates as many problems as it solves.”

“It does. And honestly, it’s the same problem as anonymization - just framed differently. You’re still deleting data dimensions to protect privacy. You still lose correlations, patterns, and visibility. You still work with fragmented data.”

The Real Need

Jessica closed her notebook. “So what do you actually need?”

“I need the production data itself - the actual patient records - but with sensitive fields transformed to protect privacy. Not deleted. Not anonymized into uselessness. Transformed in a way that removes patient identifiability while preserving the statistical patterns, correlations, and relationships we need for machine learning.”

“Give me an example.”

“Patient names and IDs - transform them completely. I don’t need to know who the patient is. But prescription refill timing relative to prescription date? Keep that intact because the behavioral pattern matters for prediction. Geographic location down to street address? Transform it to census tract or region. I don’t need precision location, but I need regional risk factors.”

“What about dates?”

“Birth dates are identifiable. But age at time of treatment? That I need precisely. Treatment dates can be shifted by a random offset as long as the relative sequence and timing between treatments is preserved. The actual calendar date doesn’t matter. The pattern does.”

Jessica was writing quickly. “So surgical transformation. Not wholesale deletion.”

“Exactly. Most of what makes someone identifiable is separate from what makes the data useful for ML. Patient name has zero predictive value for readmission risk. But medication adherence patterns have enormous predictive value. Traditional anonymization doesn’t make that distinction. It removes entire dimensions to be safe.”

“And synthetic data?”

“Synthetic data regenerates everything from statistical distributions. It looks like data, but it doesn’t behave like data we need for ML. All the edge cases, the comorbidity patterns, the temporal correlations - they get smoothed out in the generation process. We need the real patterns from real patient behaviors, just with the identifiable parts transformed.”

David paused. “Now, I know what Maria will ask - and she should ask it: How do we measure re-identification risk in the transformed data? How do we know that the patterns we preserve can’t be used to re-identify patients? That’s the technical question I can’t answer alone. That’s where we need her expertise combined with ours. I’m not proposing we ignore re-identification risk. I’m proposing we measure and manage it through transformation rather than trying to eliminate it through deletion.”

He added: “And there’s another consideration - if we mask certain demographic fields too aggressively, we might not be able to audit our models for bias. We need to think about fairness. Can we still detect if a model has racial or socioeconomic bias if we’ve removed those attributes? That’s something we’ll need to work out.”

Jessica looked up. “So you’re acknowledging the complexity.”

“Absolutely. This isn’t a simple solution. But the principle is sound - we can transform rather than delete. The details of how we do that safely? That’s the conversation we need to have with Maria, with Lisa, with James. But we can’t have that conversation if we’re stuck debating whether to use production data at all.”

The Timeline

“How long can your team keep working like this?” Jessica asked.

David thought about Sarah’s message. About the 847 data requests. About the models that kept failing despite enormous effort.

“Honestly? Not much longer.” He met her eyes. “Jessica, I’m going to be direct. Three of my best people have had conversations with recruiters in the last six months. Not because the work isn’t interesting. Because they can’t actually do the work. They spend more time fighting data access than building models.”

He leaned forward. “And here’s the organizational problem - Maria is measured on breach prevention. I’m measured on model accuracy. Our incentives are completely misaligned. So instead of solving this together, we fight over data access requests. She becomes the bottleneck everyone resents. I become the person asking for risky things. Neither of us wants that.”

Jessica was quiet for a moment. “Give me few days. I need to talk to Maria, to Lisa, to James. I need to understand everyone’s constraints. Then I need to find the approach where transformed production data works for all of you.”

“You think that exists?”

“Two weeks ago, I asked myself why we’re stuck choosing between reckless and paralyzed. I think it’s because we’re asking the wrong question. Not ‘Should we use production data?’ but ‘How do we transform production data so both you and Maria can say yes?’”

“And if you can’t find it?”

“Then I’ll tell you directly. But David, I’ve been at companies that solved hard problems by reframing them. This feels like one of those.”

The Hope

That evening, David looked at his team’s Slack channel. The frustration was palpable.

Marcus: “Request #851 rejected. They said the field correlation we need could theoretically enable re-identification through pattern matching.”

Jen: “Is there ANY data we can actually use for exploration?”

Shreya: “At this point I’m starting to think we should just accept that our job is to build models that don’t work and call it a day.”

David started typing a response, then stopped.

He couldn’t promise them it would get better. He couldn’t tell them Jessica would solve it.

But he could tell them someone was finally asking the right question.

He typed: “Jessica asked me today what we actually need. Not what’s possible under current constraints. What we actually need to do our jobs. I told her: production data with sensitive fields transformed, not deleted. She’s working on it. Three weeks.”

Marcus replied: “I’ve heard ‘working on it’ before.”

“I know,” David typed back. “But this time feels different. She’s asking how to transform the data, not whether we can use it. That’s new.”

Jen: “I hope you’re right.”

So did David.

Because the alternative was watching his team’s skills atrophy while they spent their careers fighting data access processes instead of solving ML problems.

There had to be a way to give them the production data they needed with the privacy protections Maria needed.

Transformation, not deletion. Precision, not wholesale removal. The real patterns, with the identifiable parts surgically altered.

And a framework to measure whether that transformation actually protected patients.

Did that exist?

David didn’t know. But it was the only question that mattered.