After working across multiple healthcare projects, I kept seeing the same pattern: different teams, different products, different markets — same crisis. We started calling it the Spaghetti Data Crisis (not copyrighted), and this post is our attempt to put a name to something that's quietly slowing down healthtech teams.

Let's set the scene. You're three months post-launch. Your health-tech startup just closed a pilot with a mid-sized clinic, or you're already running with a few hundred users. Congrats. Seriously. That's a significant milestone.

Everything is moving fast. Your backend, for example, has a patient object that started as a JSON document in a MongoDB collection, grew into a relational table, and then was extended with five ad-hoc fields because every new feature needed just one more thing.

The client is now asking you to integrate with their EHR. You pull up the codebase and realize: there's no standard. No schema that anyone outside your team would recognize. No clear boundary between what a "patient" is, what an "encounter" is, or how a "medication" relates to either. It's all custom. All yours. All unmaintainable.

Welcome to the Spaghetti Data Crisis.

The Inflection Point: When Custom Chaos Becomes a Risk

Here's the thing — if you've found yourself in this situation, it doesn't mean you failed. Anyone who's built in this space knows that the "right" data architecture isn't just about how you store data. It's about where, what, security, cost, compliance, and a dozen other constraints that don't have clear answers when you're a small team with limited runway. How many pilots actually go to production overnight?

The good news? You're not too late. You're just at the inflection point.

This is the moment that separates healthtech companies that scale from those that spend the next months/years paying down technical debt instead of expanding.

The point isn't a single event. It usually looks like one of these:

• A health system asks for an FHIR API during procurement, and your team realizes you'd have to rebuild your entire data layer to support it.
• You try to pull analytics across patients and encounters, and nobody can agree on what fields mean what because three engineers built three slightly different versions of the same concept.
• A compliance audit reveals inconsistencies between how your app stores data and what HIPAA requires you to report.
• You lost a deal because your competitor had a FHIR-native integration, and you didn't.

At this point, teams typically do one of two things: they double down on the custom model ("we'll clean it up later") or they face the music and start thinking about standards. The ones who delay usually face a much harder refactor 12 months later — when they can least afford it.

FHIR in Practice: You Probably Need Less Than You Think

Before we get into why we always recommend moving toward this approach, it's worth pausing to clarify: the right entry point depends on where you currently stand.

1. If you're just getting started, whether with your own team or alongside a development partner (like Xmartlabs ❤️), do everything you can to adopt FHIR as your standard from day one. Later in this post, we'll show how, even for engineers with no FHIR experience, the short-term learning curve pays off quickly. It's a win-win.
2. If you're already in production and feeling the pressure of the crisis we described above, the good news is that you can start taking meaningful action at a relatively low operational and budget cost. You don't need a full rewrite to break through the inflection point; you need a strategy, and we'll share a few on this blog later.

Now, back to the core question: why FHIR specifically?

Beyond being the most widely adopted standard in healthcare today, FHIR has something that most technical standards don't — a documentation ecosystem rich enough for both engineers and non-technical stakeholders to engage with on their own terms. That shared language matters more than people expect. It means your clinical advisor, your compliance team, and your backend engineer can sit in the same room and actually understand each other.

Theory is useful. But here's what this actually looks like in practice.

Real case #1 — Building from scratch VR-powered consultations in challenging environments

A client needed to manage medical consultations delivered via VR in physically or logistically demanding settings, such as remote locations, high-stress environments, and areas with limited connectivity. Because we mapped FHIR resources to the consultation model from day one, the entire data layer was built around standard entities. With just a handful of resources, the product interoperated with external services without any structural rework. No custom translation layers. No retrofitting. The standard did the heavy lifting before the product even reached its first users.

The takeaway: Starting with FHIR adds some upfront weight, a steeper learning curve, and a few more decisions to make early on, but it removes an entire category of future problems. The kind that show up at the worst possible moment, when you start to scale.

Real case #2 — Already in production, Turning voice into structured clinical data

A health services provider was generating hours of clinical voice conversations with no standardized output — just raw audio and informal notes. The goal was to turn those conversations into automated, structured transcripts that could plug into existing clinical workflows. The product already had traction but lacked a standard data model. Rather than a full rewrite, we ran a modular rollout: incrementally introducing FHIR-aligned structures by service area, using out-of-the-box tools where possible. Each module became interoperable without breaking what was already working.

The takeaway: You don't need to stop shipping to fix your foundation. A modular approach to FHIR adoption lets you reduce technical debt without losing momentum.

🗒️ A practical note: In the vast majority of cases, especially for focused, single-problem products (which tend to be the ones that win), you don't need to implement the full FHIR specification. Not even close. Getting fluent in just a handful of core resources: Patient, Practitioner, Encounter, Observation, Condition, and MedicationRequest will cover roughly 90% of your data model needs.

Start there, and then do the whole transition if needed.

Now That You're Convinced: The Pragmatic FHIR Stack

The most common mistake teams make after deciding to adopt FHIR is trying to boil the ocean. They download the full spec, open the HL7 documentation, and close the tab three minutes later.

Here is what worked for us, broken into three layers.

1. Knowledge Boost: Learn the Standard

• FHIR for Developers (HL7 official) — The official developer overview. Read it once, top to bottom. It is shorter than you think.
• Smile CDR's FHIR Learning Center — One of the clearest practical introductions available, written by people who build FHIR infrastructure for a living.
• FHIR Fundamentals Course (Medblocks) — A beginner-friendly, hands-on course covering FHIR resources, REST APIs, transactions, search, and cloud FHIR servers. Great if you prefer structured learning over reading the specification directly.
• Simplifier.net — A massive repository of Implementation Guides, profiles, and examples used by healthcare organizations worldwide.
• US Core Implementation Guide — Essential if you are going to write Implementation Guides or define custom profiles.
• The #fhir Zulip chat — An active community where you can ask very specific implementation questions and get answers from people who maintain the spec itself.

💡Tip: Assign a team member as the internal FHIR SME lead. Not a permanent role, just someone who goes deeper and becomes the go-to reference for the rest of the team for the first few months.

Fair warning: this one is for the engineers on the team. Once you have enough shared context, the next question is tooling. The good news is that the ecosystem has matured significantly. You do not need to build everything from scratch.

2. FHIR Servers (managed or self-hosted):

• HAPI FHIR — Open source, Java-based, battle-tested. If you want full control and are comfortable running your own infrastructure, this is the most widely adopted open source option.
• Azure Health Data Services / Google Cloud Healthcare API / AWS HealthLake — Managed FHIR servers if you are already on one of the major clouds and want to avoid infrastructure overhead early on. We leaned on these early precisely because we did not want to maintain a server while also building a product.
• Medplum — A newer, developer-friendly FHIR platform with a strong DX focus. Worth evaluating if you want a modern API-first approach without heavy enterprise overhead.
• FHIR Developer Skill (Anthropic) — A practical AI-assisted development guide for building FHIR APIs. Covers resource validation, OperationOutcome errors, correct HTTP status codes, SMART on FHIR authorization, and common coding systems such as LOINC, SNOMED CT, RxNorm, and ICD-10. Particularly useful when implementing FHIR endpoints with tools like Claude Code or Cursor.

We have used both Google Cloud Healthcare API and Medplum in real-world projects and can confidently recommend both. Google Cloud Healthcare API is an excellent choice if you are already invested in Google Cloud and want a fully managed FHIR infrastructure layer. Medplum, on the other hand, is much more than a FHIR server: it is an open-source healthcare development platform that includes core EHR capabilities such as patient management, scheduling, forms, communications, and authentication out of the box. This makes it particularly attractive when developer experience, rapid prototyping, and launching a production-ready healthcare application are the priority. We are also actively exploring AWS HealthLake as another managed option within the Amazon Web Services ecosystem.

3. Management: Project and Data Governance

Technical execution and information governance go hand in hand. Not a groundbreaking insight for anyone who has shipped software before. But in healthtech, the cost of getting this wrong is higher than in other domains. So alongside the technical stack, we always pair a set of non-technical practices that save us from future headaches:

Define your core resource inventory first. Before writing any profiles or standing up a server, map out which FHIR resources are actually relevant to your product. Most early-stage healthtech products require fewer than 10 resource types to get started. Patient, Observation, Encounter, Condition, MedicationRequest, Practitioner, and Organization cover most clinical workflows. Write this down. Make it visible. It becomes your team's shared vocabulary.

Establish a FHIR version policy and review it periodically. Pick a version upfront (R4 is the current standard for most US regulatory and interoperability requirements) and document it explicitly. But do not treat it as a one-time decision. Schedule a lightweight quarterly review to assess how your resource mappings have evolved, whether any new profiles are relevant to your use case, and whether R5 adoption in your target integrations is accelerating. Mappings drift silently over time. A periodic review is the cheapest way to catch that drift before it becomes a migration project.

Involve a clinical informatics person early, even informally. If you do not have one on staff, find an advisor or consultant who can review your resource mappings. Clinical data has semantic nuance that engineering instincts alone do not always catch. A Condition is not the same as a Diagnosis. An Observation value has units that matter. Getting this wrong early means having to clean up data integrity issues at the worst possible time.

What's Next?

Hope this was useful, wherever you are in your journey. Whether you are staring down the inflection point or already past it, the goal here was to share some of what we have learned, without pretending there is one right answer for every startup.

This is the first of three posts on this topic. Partly because trying to fit everything into one piece felt like bad advice in itself. And partly because we, or at least I, know how frustrating it is to read something that does a good job of naming a problem, throws out a few tips, and then leaves you without a path forward. I have been on the receiving end of that too many times as a developer. The next two posts will go deeper into the actual solutions: concrete implementation, real tradeoffs, and the things we wish someone had told us earlier.