I Used Claude Code to Get a Second Opinion on My MRI: What Product Builders Can Learn About AI in Healthcare
TL;DR
- A developer successfully used Claude Code (Opus) to analyze their MRI scan, demonstrating AI's potential as a supplementary diagnostic tool that can provide accessible second opinions outside traditional healthcare workflows.
- The experiment highlights a critical product insight: AI tools are most valuable when they augment human expertise rather than replace it, especially in high-stakes domains like healthcare where liability and accuracy are paramount.
- Product builders entering healthcare AI must navigate a complex landscape of regulatory requirements, liability concerns, and the fundamental need to position AI as a decision-support tool rather than a diagnostic authority.
- The real opportunity isn't building "AI doctors" but creating intelligent interfaces that make medical information more accessible and interpretable for both patients and healthcare providers.
When Your MRI Needs a Second Set of Eyes (Or Tokens)
Here's a scenario that's becoming increasingly common: You've just had an MRI. Your doctor has reviewed it, but you're left with questions. Maybe the radiologist's report used terminology you don't fully understand. Maybe you want to know what specific findings mean for your daily activities. Maybe you're simply curious about what that imaging actually shows.
Traditionally, getting a second opinion meant scheduling another appointment, waiting weeks, and paying another specialist. But Antoine's experiment using Claude Code to analyze his MRI demonstrates a fascinating alternative that product builders should pay close attention to: using AI as an accessible interpretive layer between medical imaging and patient understanding.
What makes this particularly interesting isn't just that it worked—it's what it reveals about where AI product opportunities actually exist in healthcare.
The Experiment: What Actually Happened
Antoine uploaded his MRI images to Claude Code and asked it to analyze what it saw. The AI provided detailed observations about anatomical structures, identified potential areas of concern, and offered interpretations of the imaging findings. Importantly, Claude maintained appropriate boundaries, consistently reminding Antoine that its analysis wasn't a substitute for professional medical advice.
This wasn't a case of AI playing doctor. It was something more nuanced and, frankly, more useful: AI serving as an intelligent intermediary that could parse complex medical imaging and translate it into understandable information.
The technical execution here matters. Claude Code's multimodal capabilities allowed it to process visual medical data and provide contextual analysis. The model demonstrated understanding of anatomical structures, radiological conventions, and medical terminology—all while maintaining appropriate epistemic humility about the limits of its analysis.
Why This Matters for Product Builders
If you're building AI products, especially in healthcare or other regulated domains, this experiment offers several critical lessons that extend far beyond medical imaging.
The Augmentation vs. Replacement Framework
My take on this is straightforward: the most successful AI products in healthcare won't be the ones that try to replace doctors—they'll be the ones that make medical expertise more accessible and actionable for everyone involved in the care process.
Antoine's use case perfectly illustrates this principle. He wasn't trying to bypass his doctor or get a definitive diagnosis from Claude. He was using AI to better understand information he already had access to. This is the sweet spot for AI in healthcare: augmenting human understanding and decision-making rather than attempting to automate it away.
Product builders often fall into the trap of maximalist thinking: "Our AI can do X, therefore we should position it as replacing X." But in domains with high stakes and complex regulatory environments, the winning move is usually more modest and more useful: "Our AI can help you understand X better, so you can make more informed decisions about X."
The Accessibility Gap Is Your Product Opportunity
There's a massive gap between medical information and patient understanding. Radiology reports are written for other radiologists. Lab results come with reference ranges but little context. Treatment options are explained in clinical language that assumes baseline medical knowledge most patients don't have.
This accessibility gap is where AI products can create genuine value. Not by providing diagnoses, but by serving as translators, explainers, and navigators through complex medical information.
Consider the product implications:
- A tool that takes a radiology report and generates patient-friendly explanations with visual aids
- An interface that allows patients to ask follow-up questions about their medical records in natural language
- A system that helps patients prepare for doctor appointments by identifying relevant questions based on their medical history and upcoming procedures
None of these require the AI to make medical decisions. They all create value by making existing medical information more accessible and actionable.
The Liability and Regulatory Reality
Let's address the elephant in the examination room: medical liability and regulatory compliance.
Antoine's experiment worked because it was a personal exploration with appropriate disclaimers. But if you're building a product in this space, you're operating in a completely different context. The FDA regulates software as a medical device (SaMD). HIPAA governs patient data. State medical boards have opinions about what constitutes practicing medicine without a license.
This isn't a reason to avoid healthcare AI—it's a reason to be strategic about positioning and scope.
The key distinction is between clinical decision support (which may require regulatory approval) and general health information tools (which typically don't). If your AI is making or suggesting specific clinical decisions—diagnose this, prescribe that, perform this procedure—you're likely in regulated territory. If your AI is explaining, translating, or organizing information for human decision-makers, you're in a different category.
Product builders need to work with regulatory experts from day one, not as an afterthought. Your product positioning, feature set, and user interface all have regulatory implications. The disclaimer text Claude includes in its responses isn't just CYA—it's a fundamental part of the product design that establishes appropriate boundaries.
The Technical Architecture of Healthcare AI Products
If you're building in this space, several technical considerations emerge from Antoine's experiment:
Multimodal Capabilities Are Table Stakes
Healthcare data is inherently multimodal: imaging, lab values, clinical notes, genomic data, wearable device outputs. Your AI product needs to handle multiple data types and understand their relationships.
Claude Code's ability to process MRI images alongside text queries demonstrates why multimodal AI is particularly valuable in healthcare. Medical decision-making rarely relies on a single data source—it synthesizes information across multiple modalities.
Context Windows Matter More Than You Think
Medical context is deep and interconnected. A patient's current symptoms might relate to conditions from years ago, medications they're taking, or genetic factors. Effective healthcare AI needs sufficient context window to maintain relevant medical history throughout a conversation or analysis.
This is why the recent expansion of context windows in models like Claude and GPT-4 is particularly significant for healthcare applications. You can include more of a patient's medical history, more reference material, and more contextual information without losing coherence.
Explainability Isn't Optional
In healthcare, "the AI said so" isn't good enough. Users need to understand why the AI is providing particular information or suggestions. This means building products with explainability baked in from the start, not bolted on later.
Antoine's interaction with Claude demonstrates this principle. The AI didn't just provide conclusions—it explained what it was seeing in the images and why certain findings might be relevant. This transparency is crucial for building trust and enabling informed decision-making.
Building Responsibly: The Product Manager's Checklist
If you're considering building AI products in healthcare, here's my practical checklist based on lessons from experiments like Antoine's:
1. Define Your Boundaries Clearly
Decide what your product will and won't do, and enforce those boundaries in both the user interface and the AI's behavior. If you're not providing diagnoses, make sure your AI consistently refuses to do so, no matter how users phrase their requests.
2. Design for the Augmentation Use Case
Structure your product around supporting human decision-makers rather than replacing them. This means building features that help users ask better questions, understand complex information, and prepare for conversations with healthcare providers.
3. Plan for Regulatory Compliance from Day One
Engage with regulatory experts early. Understand which regulatory frameworks apply to your product and design accordingly. This isn't just about avoiding legal problems—it's about building a sustainable business.
4. Prioritize Data Privacy and Security
Healthcare data is sensitive. Your security and privacy practices need to exceed baseline standards. This means encryption at rest and in transit, careful access controls, clear data retention policies, and transparent communication with users about how their data is used.
5. Build in Quality Assurance Mechanisms
AI models can hallucinate, misinterpret, or provide outdated information. Implement quality assurance processes that catch errors before they reach users. This might include confidence scoring, cross-referencing with trusted medical databases, or human review of AI outputs.
6. Create Clear User Expectations
Your onboarding, user interface, and communication should consistently set appropriate expectations about what your AI can and cannot do. Users should understand they're using a tool to better understand information, not receiving medical advice.
The Broader Implications for AI Product Strategy
Antoine's MRI experiment is a microcosm of a larger shift in how we think about AI capabilities and applications. We're moving from "can AI do this?" to "how should AI do this in a way that's useful, safe, and sustainable?"
This shift is particularly pronounced in healthcare, but the lessons apply broadly:
Capability doesn't equal product. Just because an AI can perform a task doesn't mean it should, or that doing so creates a viable product. The question isn't just technical capability—it's about value creation, risk management, and sustainable business models.
Context matters more than raw performance. An AI that's 95% accurate in a lab might be useless or dangerous in real-world deployment if it can't handle edge cases, doesn't integrate into existing workflows, or creates new problems while solving old ones.
The interface is the product. How you present AI capabilities, what boundaries you enforce, and how you guide user behavior are as important as the underlying model. Claude's consistent disclaimers and boundary-setting aren't bugs—they're features that make the interaction safe and valuable.
What's Next: The Evolution of Healthcare AI
We're still in the early innings of AI in healthcare. Experiments like Antoine's are valuable because they explore possibilities and surface challenges that inform the next generation of products.
I think we'll see several trends emerge:
Specialized healthcare AI tools will proliferate. Rather than general-purpose medical AI, we'll see focused tools for specific use cases: radiology interpretation aids, clinical note summarization, patient education, treatment planning support. Each will be designed for its specific context with appropriate guardrails and capabilities.
Integration with existing healthcare systems will become critical. Standalone AI tools are interesting, but the real value comes from integration with electronic health records, imaging systems, and clinical workflows. Product builders need to think about interoperability from day one.
Regulatory frameworks will mature. As AI becomes more prevalent in healthcare, regulatory bodies will develop clearer guidelines and frameworks. Early movers who engage constructively with regulators will help shape these frameworks and gain competitive advantages.
The human-AI collaboration model will become standard. We'll move beyond the "AI vs. humans" framing to sophisticated collaboration models where AI and human expertise complement each other in well-defined ways.
The Bottom Line for Builders
Antoine's experiment with Claude Code and his MRI isn't just a cool tech demo—it's a case study in how AI can create value in complex, regulated domains by augmenting human capabilities rather than replacing them.
For product builders, the lesson is clear: the biggest opportunities in healthcare AI aren't in building systems that replace doctors, but in creating tools that make medical expertise more accessible, medical information more understandable, and medical decision-making more informed.
This requires technical sophistication, yes, but also regulatory awareness, ethical consideration, and a clear-eyed view of where AI adds value versus where it introduces risk. It means building products that are genuinely useful rather than merely impressive, that solve real problems rather than demonstrating technical capabilities.
The future of healthcare AI isn't about artificial intelligence replacing human judgment—it's about augmenting human intelligence with artificial capabilities, creating systems where both humans and AI do what they do best. That's a future worth building toward, one carefully designed product at a time.
If you're building in this space, start with a clear understanding of your boundaries, a deep respect for the domain's complexity, and a commitment to creating genuine value for all stakeholders—patients, providers, and healthcare systems. The opportunity is enormous, but so is the responsibility. Build accordingly.
Frequently Asked Questions
Can AI tools like Claude legally analyze medical images?
For personal use and educational purposes, individuals can use AI tools to better understand their own medical images. However, if you're building a commercial product that analyzes medical images, you likely need FDA approval as a Software as Medical Device (SaMD), especially if the tool is used for clinical decision-making. The key distinction is between personal exploration (what Antoine did) and clinical use (which requires regulatory approval).
Should I use AI to get a second opinion instead of seeing another doctor?
No. AI tools should complement, not replace, professional medical advice. While AI can help you better understand your medical images or reports, it cannot account for your complete medical history, perform physical examinations, or take legal responsibility for clinical decisions. Use AI to prepare better questions for your healthcare provider and understand medical information more clearly, but always consult qualified medical professionals for actual medical decisions.
What are the biggest risks of building AI products in healthcare?
The primary risks include regulatory non-compliance (which can shut down your product), liability issues if your AI provides incorrect information that leads to harm, data privacy violations under HIPAA and similar regulations, and reputational damage from overpromising capabilities. Additionally, there's the risk of building something technically impressive but clinically useless if you don't deeply understand healthcare workflows and actual user needs.
How do I position an AI healthcare product to avoid regulatory scrutiny?
Focus on information and education rather than diagnosis or treatment recommendations. Position your product as a tool that helps users understand and organize medical information, not one that makes clinical decisions. Work with regulatory consultants early to understand boundaries, implement clear disclaimers, and design your product to support human decision-making rather than replace it. Remember that avoiding regulation isn't the goal—building a compliant, valuable product is.