AI in Healthcare Needs a Reality Check: Start with FHIR, Not Fancy Algorithms

Everyone thinks the biggest problem with AI in healthcare is the algorithms. They're wrong. The real bottleneck is the data itself—messy, siloed, trapped in systems that can't talk to each other. No amount of machine learning wizardry can compensate for data that's incomplete, inconsistent, or simply inaccessible. That's why the most important AI decision you'll make isn't about models—it's about interoperability standards.

Stop Chasing AI Buzzwords—Fix Your Data Plumbing First

Walk into any health IT conference and you'll hear about deep learning for radiology, natural language processing for clinical notes, predictive analytics for readmissions. But ask how those models get the data they need, and the room goes quiet. The ugly truth: most EHRs still rely on HL7 Version 2, a messaging standard first published in 1987. It's still used by more than 95% of US healthcare organizations (HL7 International). That's not inherently bad—it's reliable and handles high-throughput legacy workflows. But it's not designed for the granular, queryable, patient-level data that modern AI craves. FHIR, on the other hand, was built for this. It uses RESTful APIs and discrete resources like Patient, Encounter, and Observation that can be independently queried and updated (HL7 International). If you're starting an AI project, you should be building on FHIR, not bolting AI onto HL7 v2 pipes.

FHIR Is Not Just Another Standard—It's the Only Realistic Foundation

FHIR isn't perfect. It's still evolving—FHIR R5, published in March 2023, is only a Standard for Trial Use, not a normative specification (HL7 FHIR Version History). But it's already the de facto standard for developer-facing, mobile, and cloud-native applications (HL7 International). The US Core Implementation Guide, based on FHIR R4, defines the minimum constraints for patient data access and has become the foundation for US Realm implementation guides (US Core Implementation Guide). That means if you're building an AI tool that needs to pull data from multiple EHRs, FHIR gives you a consistent, modern API. You can query a specific patient's observations, get a structured result, and feed it into your model. With HL7 v2, you'd be parsing pipe-delimited messages, hoping the sending system used the same segment mappings. It's a nightmare. The evidence is in the adoption numbers: as of 2021, 96% of US non-federal acute care hospitals had adopted certified health IT (ONC/HHS Report to Congress). That's a massive installed base. The only way to make that data useful for AI is through a standard that's designed for interoperability, not just messaging.

But What About Legacy Systems and Vendor Lock-In?

You might argue that switching to FHIR is too costly, that your HL7 v2 interfaces are working fine, and that vendors won't cooperate. Fair enough. But here's the thing: FHIR doesn't require a rip-and-replace. It can coexist with HL7 v2. Many organizations are running both—HL7 v2 for high-throughput legacy workflows, FHIR for new applications (HL7 International). The investment is in building FHIR APIs, not in replacing your EHR. And the regulatory winds are blowing that way anyway. The 21st Century Cures Act made sharing electronic health information the expected norm, and information blocking is now illegal for providers, developers, and HIEs (ONC/HHS Information Blocking). The ONC moved the applicability date to April 5, 2021, and has been enforcing it (ONC/HHS Information Blocking FAQ). So you don't have a choice—you have to make your data accessible. Why not do it in a way that also sets up your AI initiatives for success?

The Real AI Opportunity: Clean, Structured Data at Scale

Think about what AI actually needs: clean, structured, semantically consistent data. FHIR gives you that—if you also invest in terminologies like LOINC and SNOMED CT. LOINC version 2.82, released February 24, 2026, contains 109,325 total concepts, including 66,861 lab concepts (LOINC). SNOMED CT is a designated standard for US federal systems (NLM). When you combine FHIR's structure with these vocabularies, you get data that's not only interoperable but also computable. That's the real prize. For example, imagine an AI model that predicts sepsis. It needs lab results, vital signs, and medication orders—all time-stamped and coded. With FHIR, you can query for all Observations for a patient, filter by LOINC codes, and get a clean dataset. With HL7 v2, you'd be parsing ADT and ORU messages, hoping the sending system used the same location in the message. It's a mess. And the penalties for getting privacy wrong are steep—the HIPAA penalty calendar-year cap is now $2,190,294 (Federal Register 2026 HIPAA CMP Adjustment). But that's about security, not interoperability. The point is: if you want AI to work, start with FHIR. It's the only realistic foundation for the data-driven future of healthcare.

Takeaway

AI in healthcare is hyped, but the real work is in data plumbing. Stop obsessing over algorithmic sophistication and start building FHIR-based APIs that expose clean, coded data. That's the first and most important step. Everything else—the models, the predictions, the clinical insights—will follow. If you ignore interoperability, your AI project will fail, not because the algorithm is bad, but because the data is. Choose FHIR. It's not glamorous, but it's the only way forward.

Sources

• HL7 International - https://www.hl7.org/fhir/
• ONC / HHS (Report to Congress) - https://healthit.gov/news/onc-outlines-health-it-interoperability-progress-report-congress/
• US Core Implementation Guide - https://hl7.org/fhir/us/core/
• LOINC - https://loinc.org/
• ONC / HHS (Information Blocking) - https://www.healthit.gov/topic/information-blocking
• Federal Register (2026 HIPAA CMP Adjustment) - https://www.federalregister.gov/documents/2026/01/28/2026-01688/annual-civil-monetary-penalties-inflation-adjustment