AI vs. ER Doctors: What a Harvard Study Just Revealed About the Future of Medicine

A new study out of Harvard University, published in Science, is raising serious questions about the future role of AI in clinical decision-making.

Researchers evaluated OpenAI o1-preview using 76 real emergency room (ER) cases—and the results weren’t subtle. The AI didn’t just perform well. It outperformed experienced physicians.

What the Study Tested

The study wasn’t theoretical or synthetic. It used:

  • Real ER patient cases
  • Raw electronic health record (EHR) text
  • Three stages of clinical decision-making

The AI had no special formatting, no structured prompts—just the same messy, real-world data clinicians deal with every day.

The Results: AI Took the Lead

At the initial ER triage stage, accuracy rates were:

  • 67.1% — AI (o1-preview)
  • 55.3% — Physician #1
  • 50.0% — Physician #2

That’s not a marginal improvement—it’s a double-digit lead in diagnostic accuracy at the most critical early stage of care.

Even more interesting:

  • Independent physician reviewers could not distinguish between AI-generated and human diagnoses.

In other words, the AI didn’t just perform better—it blended in seamlessly with expert-level clinical reasoning.

A Real-World Moment That Stands Out

One case in particular highlights the potential impact:

  • The AI flagged a rare flesh-eating infection (necrotizing condition)
  • In a transplant patient
  • 12–24 hours before the treating physician identified it

That kind of time advantage isn’t academic—it can be the difference between life and death.

What This Actually Means (And What It Doesn’t)

Let’s be clear: this does not mean AI is replacing doctors.

But it does signal something more practical—and arguably more powerful:

1. AI as a Second Set of Eyes

Doctors operate under pressure, fatigue, and time constraints. AI doesn’t.
A system that consistently flags edge cases or rare conditions can act as a real-time diagnostic safety net.

2. Pattern Recognition at Scale

AI models trained across vast datasets can detect patterns that are:

  • Rare
  • Non-obvious
  • Easily missed in fast-paced environments like ERs

3. Decision Augmentation, Not Automation

The real value isn’t in replacing clinicians—it’s in augmenting their judgment, especially during:

  • Triage
  • Differential diagnosis
  • Risk identification

The Bigger Shift: AI Helping Doctors, Not Just Patients

Millions of people already use AI tools for personal health questions.

This study flips the narrative:

AI isn’t just for patients anymore—it’s becoming a tool for clinicians themselves.

And if a 2024-era model is already outperforming physicians in controlled settings, the trajectory is hard to ignore.

Where This Could Go Next

If integrated responsibly into clinical workflows, AI could:

  • Reduce diagnostic errors
  • Improve triage prioritization
  • Accelerate identification of rare conditions
  • Provide continuous clinical support in high-load environments

But this also raises real questions:

  • How do we validate and regulate these systems?
  • Who is accountable for AI-assisted decisions?
  • How do we integrate without over-reliance?

Final Thought

We’re not looking at a distant future scenario anymore.

We’re looking at a present-day signal:

AI is already capable of matching—and in some cases exceeding—human diagnostic performance in high-stakes environments.

The next phase isn’t about proving capability.

It’s about figuring out how to safely and effectively put that capability to work inside real healthcare systems.

https://www.science.org/doi/10.1126/science.adz4433

Debugging an IIS-Hosted ASP.NET Core API on Azure VM: A Real-World Walkthrough

Overview

This article walks through a real-world debugging scenario involving an ASP.NET Core API deployed on an Azure VM behind IIS. The issue initially appeared to be a connectivity or deployment problem but ultimately turned out to be related to IIS hostname bindings and SNI (Server Name Indication).

The goal was to validate API availability directly on the VM and isolate issues between Azure routing, IIS configuration, and application behavior.

Step 1: Initial Problem

The API endpoint:

https://foo-vm.example.com/service/ProcessRequest

was returning:

404 Not Found

This raised several possible concerns:

  • Deployment failure
  • IIS misconfiguration
  • Routing issues
  • Network or SSL problems

Step 2: SSL / Certificate Validation

While testing direct HTTPS calls, the following error appeared:

Could not establish trust relationship for the SSL/TLS secure channel

Action Taken

  • Exported the server certificate (.cer)
  • Installed it on the local machine (Trusted Root / Intermediate store)
  • Alternatively, used curl with -k to bypass SSL validation:
curl -k https://foo-vm.example.com

Outcome

  • SSL issues were eliminated as a blocker
  • Able to reach the server over HTTPS

Step 3: Direct API Testing with curl

Multiple endpoints were tested:

curl -k https://foo-vm.example.com/
curl -k https://foo-vm.example.com/service/health
curl -k https://foo-vm.example.com/api/health

Result

All returned:

404 Not Found (Microsoft-IIS/10.0)

Insight

  • Requests were reaching IIS
  • But no matching route/application was found

Step 4: Validate Application Deployment

A simple health check endpoint was introduced:

/service/health

Expected response:

Healthy

However, even this endpoint returned 404 when accessed via the VM hostname.

Step 5: IIS Investigation

Upon inspecting IIS:

  • The API was not hosted under Default Web Site
  • Instead, it was hosted under a separate site:
Foo.ApiSvc

Key Finding

Requests to:

https://foo-vm.example.com

were hitting:

Default Web Site ❌

—not the actual API site.

Step 6: Binding and SNI Discovery (Root Cause)

IIS bindings for the API site showed:

Host Name: foo.example.com  
Port: 443  
SNI: Enabled

Critical Insight

With SNI enabled, IIS routes requests based on the Host header.

So:

https://foo-vm.example.com  → Default Web Site → 404  
https://foo.example.com     → Foo.ApiSvc → API

Step 7: Validate Using Host Header Override

Since DNS for foo.example.com was not directly usable from the VM, the Host header was manually injected:

curl -k https://foo-vm.example.com/service/health \
  -H "Host: foo.example.com"

Result

Healthy

Conclusion

  • API was functioning correctly
  • IIS routing was working as designed
  • Issue was purely hostname-based routing

Step 8: Azure Layer Insight

The /service/... route seen earlier was part of the Azure routing layer, not IIS.

Architecture:

Azure Front Door / Gateway
    ↓
foo.example.com
    ↓
Azure VM (IIS with SNI)
    ↓
ASP.NET Core API

Key Takeaway:

When bypassing Azure and hitting the VM directly, you must:

  • Use the correct hostname
    OR
  • Override the Host header

Application Pool Configuration Update

The IIS application pool was updated from .NET CLR v4.0 to No Managed Code to align with ASP.NET Core hosting best practices.

ASP.NET Core applications run on the CoreCLR in a separate process and do not depend on the IIS-managed CLR. While the previous setting did not prevent the application from running, updating it improves clarity and avoids confusion in future maintenance.

Step 9: Final Resolution

✅ Correct endpoint:

https://foo.example.com/service/health

✅ Or direct VM access with Host override:

curl -k https://foo-vm.example.com/service/health \
  -H "Host: foo.example.com"

Key Learnings

1. IIS with SNI routes based on hostname, not IP

Incorrect hostname results in routing to the wrong site and returns 404.

2. Default Web Site is not always your application

Always verify IIS site bindings and application mapping.

3. Azure routing can mask backend behavior

The /service path was part of the Azure layer, not IIS configuration.

4. curl is a powerful debugging tool

  • -k bypasses SSL issues
  • -v shows detailed request/response
  • -H allows header injection

5. ASP.NET Core hosting configuration

  • App pool should be set to No Managed Code
  • Runtime and hosting bundle were already functioning correctly

Final Summary

What initially appeared to be a deployment or API issue was ultimately traced to a hostname binding mismatch caused by IIS SNI configuration.

Once the correct hostname was used—or injected via the Host header—the API routed correctly and responded as expected.

Root cause: Incorrect Host header when bypassing Azure routing
Resolution: Use the correct hostname or override the Host header

🇺🇸 White House vs. Anthropic: The Mythos AI Standoff

A growing dispute between the White House and Anthropic is exposing a deeper issue in the AI race: who gets access to the most powerful models — and when.

At the center of the debate is Anthropic’s advanced AI system, Mythos, and a proposed expansion that would significantly increase private-sector access.

https://images.openai.com/static-rsc-4/SyJMouZcz0033VjO2fdICOJITdPmTbl8EmuLa7BwbpkUDap1dopYLgknpGPhjLRf1x0v-pbpn-_4kPJ4ezqzKAwQzNRQ9OIE8sS5Bgg4cCvfXL9sOp930qkMZc-uAomvhQeMPgrLKSIUTl0GMwUR0qaMDC8QKXpC828ohi3VHkeHPrHEjd4PPf5198xKEea4?purpose=fullsize
https://images.openai.com/static-rsc-4/UKD0D78L5wDWrxvZ27Bv2JqIFm8c3Vw9KEOxdNahS1OEWVYL3kKhbnSv4dl-j-Q-mDv1KDePZflSwmsz8yB25DPqRNcfvIeNJL2sbzq8bM5h6fzwS9pLhnNnf1ySK-boeD6s2kH2KQCS037_0607NorqlkR9RZFbmOkoPXFDXBE9rOef63SUXlhA4RutVSwJ?purpose=fullsize
https://images.openai.com/static-rsc-4/qOdX9pSI3xphTvSGAaYzwV1oQq-Kze6fAP40TzASczOIesTT7E5O4c4YlGETKkTbaUus3WDoHd53Xc0rH8IyeVOU5BEPdLbh0-cv_5moIKkOqmZ7RXihFqu75OrzczYDHPzczD7YJ6pDjzKf8-X2MDj6WE3C_tfJ-9LQSCYh0AEy8JbinVQMO59JOOO2iCWp?purpose=fullsize

🔍 What’s Happening

Anthropic had plans to expand Mythos access from roughly 50 companies to nearly 120. On paper, it looks like a typical scale-up move. In practice, it triggered concern inside the U.S. government.

Officials pushed back, citing compute constraints — the fear that expanding access could strain infrastructure and limit availability for federal use, particularly in sensitive domains tied to defense and intelligence.

This friction comes as a new AI policy memo from the White House is being finalized — one that could reshape how agencies adopt and procure AI systems.

🧠 Policy Shift: Multi-Vendor AI Strategy

The upcoming memo is expected to encourage multi-vendor AI adoption across federal agencies, reducing reliance on any single provider.

This is a notable shift.

It also reportedly includes provisions that would allow agencies to bypass certain supply chain risk classifications, a move that could ease tensions with companies like Anthropic — even as legal and strategic disagreements continue.

In short: the government wants flexibility, redundancy, and leverage.

⚔️ Internal Friction in Washington

The situation isn’t just a government vs. company issue — there’s also disagreement within Washington.

Comments from figures like Pete Hegseth highlight a harder stance toward Anthropic, while others appear more focused on ensuring continued access to frontier AI capabilities.

This reflects a broader split:

  • One side prioritizes control, risk mitigation, and ideological scrutiny
  • The other prioritizes access, capability, and strategic advantage

🤖 The Bigger Picture: AI Parity Is Coming Fast

Adding urgency to the situation, models like GPT-5.5 are reportedly approaching similar cyber and reasoning capabilities as Mythos.

Former AI policy lead David Sacks suggested that most frontier models could reach comparable capability levels within six months.

If that timeline holds, exclusivity becomes temporary — and the battle shifts from who has access to how widely it’s deployed.

⚠️ Why It Matters

This isn’t just a policy disagreement — it’s a preview of how AI power will be managed:

  • Compute is now a strategic resource, not just a technical constraint
  • Access to frontier models is becoming a geopolitical lever
  • Government and private sector priorities are increasingly misaligned

The White House appears to be recalibrating — not necessarily backing away from Anthropic, but ensuring it doesn’t become dependent on any single player.

At the same time, internal divisions suggest that the U.S. is still figuring out how to balance innovation, control, and national security in the AI era.

If you zoom out, the signal is clear:
AI isn’t just a technology race anymore — it’s an infrastructure, policy, and power struggle all at once.

https://www.wsj.com/tech/ai/white-house-opposes-anthropics-plan-to-expand-access-to-mythos-model-dc281ab5

Biohub Bets $500M on “Virtual Biology” to Teach AI How Cells Behave

The push to scale AI beyond text and images is heading straight into biology—and the stakes couldn’t be higher.

https://images.openai.com/static-rsc-4/esGFaIJb80Q_BNGpDqbQvRuF6aQxhL9FPPPDZQ3MYc67iK8zkYDJiHWZdQY8CobdNpejg5eQdHyCSVH0omcpxKWlqstYT1OS_ooqtBmHRqO4lk_bwKx5ynU_JuhXkrNBjGd8BamfwCh5P55SsPn1cD09YoQV8FHuPBHfdaA3zG0qW0i2VVY6l9Y-cDDRwwf8?purpose=fullsize
https://images.openai.com/static-rsc-4/387H7dq7GRK1xS1zFbol6ym1Q3WQ-RQHR31XmkfcWdUpqXT8SJU50MgVaYWAfibxYJH-8o55h6H-GocwXZLR6GWFc6MWVpw9x1ylh70SzF1jUzub2FlxS5ULeKzpiONZErKJoAX81BiCQPBKDptmRUucD70gAYQDEWk_7CKbXyIc9K0GPpEEkK27UyOMNStp?purpose=fullsize
https://images.openai.com/static-rsc-4/kVCDcjbRQ83e8msDlUEYyuvpTxKcCoVqUiz0TFm2UmhO9i33vWYt_vh0Ds6awEitcoeUjgtYYIUS29oEQ90NlrGZDdG8qd18gqn2iwLCFcw4brmvW9NhdBpKqOYd-sxo_4S1vNIdvz3Ehd6iBVuG3_XhGpX1w1WCFMFtVCzUxEAuDaU98_QwHIjH4z9dVWkz?purpose=fullsize

Backed by Mark Zuckerberg and Priscilla Chan, the Chan Zuckerberg Initiative’s Biohub has announced a $500M Virtual Biology Initiative aimed at building massive, open datasets and models that can predict how human cells behave.

The Big Bet: Data First, Models Second

The initiative is structured around a simple but ambitious premise: biology needs better data before AI can truly transform it.

  • $400M is earmarked for large-scale data generation and advanced imaging technologies
  • $100M will support external labs and collaborative research
  • Partners include organizations like Nvidia and the Allen Institute

Biohub is also committing to open datasets, positioning this as shared infrastructure rather than a closed, proprietary race.

Why This Matters: Biology Isn’t Language

Today’s AI breakthroughs were fueled by internet-scale data. Biology isn’t there yet.

Current datasets top out around ~1 billion cells, but researchers like Alex Rives argue we need an order of magnitude more to unlock meaningful predictive power. The goal isn’t just classification—it’s simulation:

  • Predict how cells respond to drugs
  • Understand disease progression at a molecular level
  • Eventually reprogram biological systems

That’s a leap from analyzing biology → to modeling and controlling it.

The Long-Term Vision

The ambition aligns with ideas from leaders like Demis Hassabis, who has suggested AI could one day help eliminate disease entirely.

Biohub’s approach is essentially:

Build the dataset → train the models → simulate biology → intervene with precision

The Real Question

We’ve seen scaling laws transform language models and protein folding. But biology is messier, noisier, and far less standardized.

Will scaling data unlock cellular intelligence the same way it unlocked GPT-level reasoning?
Or does biology require fundamentally new paradigms beyond brute-force scale?

Bottom Line

Biohub isn’t just funding research—it’s attempting to build the foundational data layer for AI-driven biology.

If it works, this could mark the shift from AI as a tool for discovery…
to AI as a system for designing and controlling life at the cellular level.

https://biohub.org/news/virtual-biology-initiative

Why Web APIs Don’t Switch Environments at Runtime

A common misconception in modern web development is that a Web API can dynamically switch between environments—such as Test and Production—based on a runtime signal like a request header or UI selection. In practice, this is not how ASP.NET Core (or most backend frameworks) are designed to operate.

The Core Principle

When a Web API starts, it is initialized with a specific environment:

ASPNETCORE_ENVIRONMENT = Development | Test | Production

This environment determines:

  • Which configuration files are loaded (appsettings.{env}.json)
  • Connection strings and external resources
  • Logging behavior and security settings
  • Feature toggles and integrations

👉 This configuration is fixed at application startup and cannot be changed per request.

Why Runtime Switching Doesn’t Work

Even if a client sends something like:

X-Environment: Production

the API will still:

  • Use the configuration it loaded at startup
  • Connect to the same databases and services
  • Execute logic based on its deployed environment

In other words:

A request can express intent, but it cannot override the API’s runtime environment.

Common Misunderstanding

Developers often attempt to:

  • Add an environment dropdown in the UI
  • Pass the selected value via headers
  • Expect the backend to “switch” environments

This leads to confusion when:

  • Test works as expected
  • Production appears unresponsive or unchanged

Because the backend is still running in its original environment.

Correct Architectural Approaches

There are three valid patterns:

1. Separate Deployments (Recommended)

  • Test UI → Test API
  • Production UI → Production API

✔ Safe
✔ Standard
✔ Aligned with enterprise practices

2. Environment-Aware Logic (Advanced)

  • Use headers or parameters to route behavior manually
  • Maintain separate configs inside the same app

⚠ Complex and risky
⚠ Requires strict safeguards

3. Hybrid (Best for Operations Tools)

  • Backend environment remains fixed
  • UI shows environment context
  • Headers used for logging, validation, or guardrails

✔ Safe
✔ Flexible
✔ Practical

Key Takeaway

A Web API’s environment is a deployment concern, not a runtime switch.

Trying to dynamically switch environments at runtime can lead to:

  • Incorrect data access
  • Security risks
  • Unintended production actions

Final Thought

Instead of forcing runtime switching, design your system so that:

  • Environments are clearly separated
  • UI reflects environment context
  • Safety mechanisms protect production

This approach is not only more reliable—it’s essential for systems operating in regulated or high-risk domains.