DEV Community: Bartosz Michalak

Unlock your Apple Health data in 15 minutes: export, analyze & ask AI anything about it

Bartosz Michalak — Fri, 20 Feb 2026 10:37:06 +0000

As you may know, extracting data from Apple Health is not straightforward. Apple doesn't expose a REST API, so if you want access to your data - say, to run some analysis or let LLMs work with it - you basically have two options:

Use a third-party app that leverages HealthKit to access your data and then sends it to a server or cloud storage like Google Drive / Dropbox. Apps like Auto Health Export exist, but they're usually paid.
Use Apple's built-in export - if you have a lot of data and you've tried this before, you know how painful this process is. The export takes several long minutes and is easy to interrupt. On top of that, if you want up-to-date data, you'd need to repeat this every single day. Good luck keeping that habit!

I've been interested in wearable data for quite some time now. As a 7+ year Apple Watch user, this problem has been bothering me for a while.

Some time ago with small team I worked on a project called Apple Health MCP. It was our first experiment with connecting wearable data to LLMs. It worked pretty well and the project got quite a bit of attention, but it remained mostly a curiosity - asking users to manually export their data was simply too much friction.

All these problems and the journey of exploring available tools led to building an ecosystem - a platform that not only lets you export your data, but also provides a backend & storage, a pretty nice UI to browse that data, and an AI layer that, through an MCP server, lets you connect your data to whatever LLM client you're using. This project is called Open Wearables - an open-source, self-hosted platform for wearable data. And it's not just Apple Health - it supports a bunch of other integrations too (Garmin, Polar, Whoop, Suunto and more).

What's interesting is that the solution could appeal to two very different audiences:

developers building applications around wearables - who would benefit from it as a middleware layer handling the complexities of provider integration, data normalisation, and so on
also individual users looking for a single place to store and access their own (or their family's) wearable data.

How to get your Apple Health data back - step by step

Let me show you how to actually get this done. The whole process takes about 15 minutes and you'll have your Apple Health data flowing into a platform where you can actually do things with it.

1. Spin up Open Wearables

First things first - you need a running instance of Open Wearables. There are basically two ways to get it running:

Option A: Deploy to Railway (easiest)

This is the fastest route. Railway gives you a one-click deploy that sets up everything - the backend, frontend, database, Redis, background workers - all pre-configured and ready to go.

Deploy on Railway

Hit the link, wait a couple of minutes, and you've got a production instance running. An admin account is created automatically on first startup (admin@admin.com / secret123) - you can customize these credentials before deploying.

Keep in mind that Railway is a paid SaaS - there's no permanent free tier. New users get a one-time $5 credit for a 30-day trial, and after that the minimum cost is $5/month (Hobby plan).

Option B: Run locally + expose with ngrok

If you prefer to keep things on your machine (or just want to poke around the code), you can run it locally:


git clone https://github.com/the-momentum/open-wearables.git

cd open-wearables

docker compose up -d

Since the mobile app needs to reach your backend over the internet, you'll need to expose it using ngrok:


ngrok http 8000

This gives you a public HTTPS URL like https://abc123.ngrok-free.app that points to your local backend. Keep this URL handy - you'll need it in a moment.

Tip: For a consistent URL that doesn't change on restart, you can set a custom domain: ngrok http 8000 --domain=your-custom-domain.ngrok-free.app

2. Create a user invitation code in the dashboard

Now that your platform is running, head to the Open Wearables dashboard. You need to create a user and generate an invitation code that the mobile app will use to authenticate.

Here's the flow:

Log in to the dashboard
Create a new user
Generate an invitation code for SDK authentication
Copy that code - you'll paste it into the mobile app in the next step.

3. Get the Open Wearables app on your phone

This is where the 'magic' happens. The app connects to Apple Health on your device and syncs data to your Open Wearables instance in the background. Two ways to get it:

Option A: Build it yourself

The SDK repository includes a fully functional example app. If you're a developer and want to see how things work under the hood:


git clone https://github.com/the-momentum/open_wearables_health_sdk.git

cd open_wearables_health_sdk/example

flutter pub get

flutter run

You'll need to open ios/Runner.xcworkspace in Xcode, select your development team, and make sure the HealthKit capability is enabled. And remember - run on a physical device, HealthKit doesn't work in the simulator.

Option B: Get a TestFlight invite

Don't want to deal with building the app? Totally fair. Join our Discord and ask for a TestFlight beta invitation - we'll get you set up.

And the app should be available in the App Store soon - completely free!

Once you have the app running, enter the invitation code and your API URL (e.g. https://api.openwearables.ai or your ngrok URL if running locally), grant HealthKit permissions, and hit sync.

Heads up: Make sure you enter the API URL, not the dashboard URL. If you're running locally, use the ngrok URL.

By default, the app syncs your entire history. If you have a lot of data - like me, with 7 years and ~5 million data points - the full sync can take around 20 minutes.

4. Browse your data in the dashboard

Once the sync kicks in, head back to the dashboard. Your health data should start appearing - steps, heart rate, sleep, workouts, and more. You can explore timeseries data, check trends, and just generally geek out over your own numbers. It's You have finally a place where you can actually work with it.

5. Talk to your data with AI (MCP)

Here's where it gets really fun. Open Wearables comes with an MCP server that lets you connect your health data to any LLM client - Claude, Cursor, or whatever you're using. Just ask questions in natural language: "How did my sleep look last week?", "Show me my heart rate trends during workouts", "Compare my step counts this month vs last month".

To get it running, you'll need your Open Wearables API key (grab it from the dashboard) and add the MCP server configuration to your LLM client. The full setup guide for Claude is available at docs, but the gist is:

Get your API key from the Open Wearables dashboard
Add the MCP server config to your client (Claude Desktop, ChatGPT)
Start chatting with your data

Have fun!

The best part? There's more than one.

But if I had to highlight a few things:

It's all Open Source. If something is missing, if you want a feature that doesn't exist yet - you can build it. Open a PR, propose changes, contribute to the project. Or just fork it and make it your own. No vendor lock-in, no waiting for someone else to prioritize your use case.
The community. We have over 100 fantastic people in our Discord, and every single one of them is passionate about wearable data. It's the kind of place where you'll find inspiration, share ideas, help each other debug things at 2 AM, and geek out over heart rate variability graphs. Whether you're a developer, a health enthusiast, or both - you'll feel at home. Come say hi.
You can do whatever you want with your data. Get creative and have fun! For example, you could build an automation in N8N that queries the Open Wearables API, checks your daily activity, and sends you a nudge on your favourite messaging app when it's time to get moving! (you can take a look at my hackathon story where I built exactly that kind of automation)

I hope this tutorial has been helpful and gets you closer to accessing your data!
Here are the links for reference:

PS Let me know if you were able to complete the setup in under 15 minutes! We care deeply about a great developer / user experience, so if there's anything we can improve, we'd love to hear your feedback!

Stop integrating wearables one by one - there's an open-source way

Bartosz Michalak — Mon, 02 Feb 2026 12:55:51 +0000

Hello all wearables enthusiasts!
(and everyone who just has to integrate with them! 😁)

If you're building a project with wearable data integrations, or just want to keep data from your personal wearables in one place - I believe you may find this article interesting. Here's a TL;DR so you can quickly assess if it's worth your time:

TL;DR:

Open Wearables = open-source alternative to expensive SaaS solutions that integrates data from hundreds of wearables
Single REST API for Garmin, Apple Health, Whoop, Polar, Suunto (and much more in the pipeline)
Self-hosted, no per-user pricing, you own the data
docker compose up and you're running

🚀 Wearables market is exploding

The popularity of wearables is growing year after year. The wearables market is worth over $200 billion in 2025 and is projected to grow to $500 billion by 2030. Over 86 million Americans (almost 1/4 of the US population) use health-related wearables. Smartwatches make up nearly half of this market.

CES 2026 was packed with health tech and wearables announcements - the industry is shifting from all-in-one devices toward specialization, with focus on battery life and AI as an active tool rather than passive tracking. Over half of the health-related exhibits were tied to the "longevity economy" (valued at $35 trillion, projected to reach $95 trillion by 2050).

If you're into Reddit, check out these subreddits to see how big the wearables communities are:

r/whoop - 132k members
r/ouraring - 297k members
r/garmin - 541k members
r/AppleWatch - 564k members

(if you're building something around wearables, I actually recommend browsing these subreddits - you'll find plenty of interesting problems that still remain unsolved)

Many people can't imagine working out without a watch on their wrist nowadays. If it's not tracked, it didn't happen!

💡 The untapped potential of wearables data

The devices collect massive amounts of data about us. For example, Apple Health has collected 5 million measurements from me over 7 years. Look at the ones that are the most numerous:

- HKQuantityTypeIdentifierActiveEnergyBurned: 1,934,715
- HKQuantityTypeIdentifierBasalEnergyBurned: 695,903
- HKQuantityTypeIdentifierHeartRate: 606,774
- HKQuantityTypeIdentifierDistanceWalkingRunning: 525,721
- HKQuantityTypeIdentifierStepCount: 339,895
- HKQuantityTypeIdentifierDistanceCycling: 156,524
- HKQuantityTypeIdentifierAppleStandTime: 117,785
- HKQuantityTypeIdentifierAppleExerciseTime: 84,134
- HKQuantityTypeIdentifierPhysicalEffort: 78,791
- HKQuantityTypeIdentifierWalkingStepLength: 50,668
- HKQuantityTypeIdentifierWalkingSpeed: 50,666
- HKQuantityTypeIdentifierRespiratoryRate: 45,750
- HKQuantityTypeIdentifierWalkingDoubleSupportPercentage: 42,814

There's a ton of raw data - and researchers are just scratching the surface of what's possible. Machine learning models are being used to predict health issues before they become critical. AI-powered wearable analysis can detect patterns in heart rate, sleep, and activity that humans would never spot. Studies show that continuous glucose monitors paired with AI are changing diabetes management. The challenge is getting all this data in one place and making sense of it.

If you want to build something meaningful with this data, you need to wrangle all these integrations yourself (or pay for an expensive SaaS). Unless you use something like...

🤔 What is Open Wearables and how can it help you?

Open Wearables is an open-source project that lets you pull data from hundreds of wearable devices through a single REST API. Instead of spending weeks wrestling with each provider's OAuth flows and data formats, you get one unified interface. It's self-hosted via Docker Compose, so you own your infrastructure and your data.

To give you a better understanding, we've prepared a diagram to show how wearables data typically flows:

As you can see, there are two ways to access wearables data:

Cloud-based (via REST API) - providers like Garmin, Whoop, or Polar expose their APIs, and Open Wearables connects to them directly
SDK-based (via Health SDK) - data lives only on the user's device (like Apple Health or Samsung Health), never hits the provider's cloud. You need a mobile app to access it and sync to your backend

Below is an example of how the Open Wearables Health SDK helps you sync user data with Open Wearables:

import 'package:health_bg_sync/health_bg_sync.dart';

class HealthService {
  Future<void> initialize() async {
    // 1. Configure the SDK
    await HealthBgSync.configure(
      environment: HealthBgSyncEnvironment.production,
    );

    // 2. Check if already signed in (session restored from Keychain)
    if (HealthBgSync.isSignedIn) {
      print('Session restored for ${HealthBgSync.currentUser?.userId}');
      return;
    }

    // 3. Get credentials from YOUR backend
    final credentials = await yourBackend.getHealthCredentials();

    // 4. Sign in with the SDK
    await HealthBgSync.signIn(
      userId: credentials.userId,
      accessToken: credentials.accessToken,
    );

    // 5. Request health permissions
    await HealthBgSync.requestAuthorization(
      types: [
        HealthDataType.steps,
        HealthDataType.heartRate,
        HealthDataType.sleep,
        HealthDataType.workout,
      ],
    );

    // 6. Start background sync
    await HealthBgSync.startBackgroundSync();
  }
}

That's it. The SDK handles background sync, retries, and data normalization. Open Wearables backend receives clean, unified data.

And when you need to fetch that data? Here's an example of getting daily activity summary:

import requests

response = requests.get(
    "http://localhost:8000/api/v1/users/{user_id}/summaries/activity",
    headers={"X-Open-Wearables-API-Key": api_key},
    params={"start_date": "2025-01-01", "end_date": "2025-01-31"}
)

# Returns daily aggregated metrics - same schema for all providers
# {
#   "date": "2025-01-15",
#   "steps": 8432,
#   "distance_meters": 6240.5,
#   "active_calories_kcal": 342.5,
#   "active_minutes": 60,
#   "heart_rate": {"avg_bpm": 72, "max_bpm": 145, "min_bpm": 52},
#   "source": {"provider": "apple_health", "device": "Apple Watch Series 9"}
# }

Simple as that! 🚀

🏗️ How is it built?

The entire project lives in a monorepo. Why? In the age of AI coding agents, monorepos make a lot of sense - LLMs work better when they can see the full picture of your codebase rather than jumping between scattered repositories. Plus, it keeps things simple: one repo to clone, one place to contribute, consistent tooling across all components.

*There's one exception to this rule - the Health SDK for Flutter lives in a separate repository.

Here's what's inside:

Backend – The heart of Open Wearables, powered by FastAPI. We use PostgreSQL for data storage and Redis for session management and caching. This is where the Provider Integration Layer lives, handling OAuth flows, data synchronization, and normalization into our unified schema.
Frontend – Our Developer Portal built with React + TypeScript. While developers use it to manage API keys, it's also useful for personal trainers monitoring their athletes or individual users who want to track health data for themselves and their families in one place.
Docs – Built with Mintlify. We focus on great developer experience, providing interactive guides and copy-paste code snippets to get you integrated quickly.
MCP – Model Context Protocol integration, so you can plug Open Wearables data directly into your AI workflows.

🚀 How to get started in minutes?

This project is built by devs, for devs. We, as core contributors, spent over 10 years building custom software for various clients - and used many different 3rd party services along the way. Some were great, but we also had plenty of frustrating experiences. That's why developer experience (DX) is our top priority here - we want Open Wearables to be the tool we wish we had.

We hate complex setups, so we made sure you can get up and running in minutes. You can start the entire stack with a single command:

docker compose up

Once you run this, you should see 7 up-and-running containers:

Then, you can run make init. This sets up your database and seeds it with real-world sample data so you can see the dashboard in action immediately. An admin account is created automatically during this process, so you can use the default credentials to log in:

admin@admin.com
secret123

Once you log in, you'll see the main dashboard:

You can see a quick summary of the system, like:

The number of users
Active connections
Total data points
A breakdown of different data types
And the latest users added to the system

The next tab you'll discover is Users.

And here’s the 'tricky' part which we're proud of: We built Open Wearables so that every action possible via API is also available in the UI. This means our platform isn't just for software developers - as mentioned at the beginning, it's powerful enough for personal trainers monitoring athletes or even families tracking their health data together.

So, if you're a software dev - you'll be using this panel mostly for monitoring purposes and managing API keys. But if you're a wearables enthusiast or personal trainer, this panel, after small adjustments, can be your operational center for wearables data! Just look at these charts you get out of the box:

If you're an Apple Watch user, the quickest way to test Open Wearables with your own data is through our demo app included in the Health SDK.

You can learn more about the SDK and how to use it in your Flutter app in the documentation.

💡 Why should you use Open Wearables as a developer?

Active community - We have a Discord server where the core team hangs out. Got stuck? Have an idea? Want to discuss a PR before submitting? We're there. There's also GitHub Discussions if that's more your style.
Full customization - It's open-source, so you can fork it, extend it, or rip out parts you don't need. Want to add a new niche wearable provider? We prepared a guide so you (or your favorite LLM) can do it without any hassle.
Skip the boring (and challenging) parts - I don't want to throw around lofty phrases like 'Save months by using X'. But just look at our git history, the number of commits and lines of code - building a stable solution that integrates wearables data is not a tivial task. OAuth flows, token refresh logic, data normalization across different providers, rate limiting, webhook handling... we've already dealt with all of that (and still fighting).

👋 Who's behind this?

We're a small, but experienced team - we've been building health & fitness apps for clients for years and kept seeing the same integration problems pop up across different projects - so we decided to solve them once and for all. Oh, and most of us are wearables enthusiasts ourselves - we actually use this stuff daily.

Core contributors:

bartmichalak - Owns product vision and roadmap, but also actively contributes to the codebase.
KaliszS - Python, Rust and Go developer in one. Good luck getting your PR past his code review - he catches every LLM hallucination.
czajkub - Python dev, mainly responsible for Apple Health integrations.
farce1 - AI wizard, maxing out his capabilities with agentic AI workflows.
FBegiello - AI/ML specialist coordinating all AI implementations around wearables data.
Gasiek - Brought many beautiful colors to the developer dashboard.
Health Kowshik - Pushing forward MCP and WHOOP integrations.

👉 Next steps

If you made it this far - thank you for your attention! Holding someone's focus these days isn't easy, so I appreciate it. Drop a comment and let me know what you think about our platform. If you're wondering what to do next, here's what I'd suggest:

Leave a star on the repo - it helps us a lot!
Run the project - docker compose up and you're good to go
Integrate your first wearable data (your users or your own!)
Join the Discord - say hi, tell us what you're trying to build
Read the docs - plenty of examples and guides there
Build something great! 🚀

Apple Health MCP Server: Use Cases for Developers

Bartosz Michalak — Thu, 06 Nov 2025 04:12:00 +0000

Apple Health MCP Server: Use Cases for Developers

Apple Health stores years of health data from workouts, sleep tracking, heart rate measurements, and step counts. While this data is valuable for building personalized health applications, accessing it has always been challenging. Apple Health exports come as complex XML files that require significant parsing effort to use effectively.

What is Apple Health MCP Server

The Apple Health MCP Server is an open-source tool that implements the Model Context Protocol, providing a clean interface for accessing Apple Health data. It takes Apple Health XML exports, indexes them in DuckDB for fast querying, and exposes the data through tools that AI agents can use naturally. The server also supports Elasticsearch integration for advanced search capabilities.

The server handles XML structure analysis, health record search, data extraction by type, and trend generation. Instead of building custom XML parsers, developers get structured access to health data through simple API calls that work with AI applications like Claude Desktop.

Why It Matters

Building health applications typically means dealing with fragmented data sources and inconsistent formats. Apple Health solves data fragmentation, but its XML export format creates technical challenges. Parsing Apple's XML structure requires domain knowledge and custom code for each data type you want to extract.

The MCP server eliminates this friction. Developers can query health data using natural language rather than writing complex parsing logic. This means more time building features that help users and less time wrestling with data infrastructure.

Use Cases for Developers

Fitness and Training Applications

Fitness apps can leverage complete Apple Health histories to create personalized workout recommendations. A running coach app can query average weekly mileage over months and analyze rest day patterns between long runs. This historical context enables realistic training progressions based on actual performance rather than user estimates.

Sleep coaching applications benefit similarly by analyzing sleep patterns alongside other lifestyle factors. They can correlate sleep quality with workout intensity, daily activity levels, and timing patterns to provide targeted improvement recommendations.

Wellness and Habit Tracking

Wellness applications help users understand connections between different health metrics. Users can discover how their step count affects mood scores or whether meditation practice correlates with stress levels measured through heart rate variability. These insights require cross-referencing multiple data types over extended periods, which the MCP server handles automatically.

The server's trend analysis tools identify patterns that would be difficult to spot manually, enabling apps to surface meaningful insights without building custom analytics infrastructure.

Corporate Wellness Platforms

Enterprise wellness solutions can analyze employee health trends while maintaining privacy. Companies building B2B wellness platforms can query aggregate activity levels across teams, helping design better wellness initiatives based on actual usage patterns rather than assumptions.

These platforms often serve clients willing to pay premium prices for personalized medicine approaches, where detailed health analysis justifies higher service costs.

Research and Analytics Tools

Researchers studying personal health patterns can access structured data from Apple Health exports without building custom parsers for each study. A research platform can quickly extract heart rate data during workout sessions across hundreds of participants, standardizing the analysis process.

Data enthusiasts building personal health dashboards can ask complex questions about their metrics without database expertise. The natural language interface makes health data exploration accessible to non-technical users while providing the depth that power users require.

AI Health Assistants and Chatbots

Developers building AI health assistants can use the MCP server to create context-aware coaching experiences. An AI assistant can notice that a user's resting heart rate has been elevated for several days while sleep quality decreased, then suggest recovery strategies based on what worked during similar periods in their historical data.

These applications become particularly powerful when they can reference years of user data to provide personalized recommendations rather than generic health advice.

Clinical Decision Support Tools

Healthcare applications can use Apple Health data to provide additional context during patient consultations. While not replacing clinical monitoring, the lifestyle data helps clinicians understand patient behavior patterns between visits.

A telehealth platform might analyze a patient's activity levels and sleep patterns leading up to reported symptoms, helping providers make more informed recommendations during virtual consultations.

Getting Started

The Apple Health MCP Server is available on GitHub with Docker setup and documentation for popular MCP clients. Development teams can integrate it into existing applications or use it as the foundation for new health-focused products.

Resources:

The server represents a significant acceleration in accessing health context for application developers. Teams can focus on creating value-added features rather than building data processing pipelines.

FHIR MCP Server: Use Cases for Healthcare Developers

Bartosz Michalak — Wed, 05 Nov 2025 12:36:34 +0000

FHIR MCP Server: Use Cases for Healthcare Developers

Healthcare systems generate vast amounts of structured clinical data through Electronic Health Records (EHRs), but accessing this information efficiently requires deep knowledge of FHIR standards and medical terminology. FHIR is the gold standard for healthcare data exchange, but its complexity often becomes a barrier for developers who want to build healthcare AI solutions.

What is FHIR MCP Server

The FHIR MCP Server is an open-source tool that implements the Model Context Protocol, providing a natural language interface for FHIR-compliant healthcare systems. It bridges the gap between complex FHIR resources and AI applications by handling the technical complexity of healthcare data standards.

The server provides full CRUD operations on major FHIR resources like Patient, Observation, Condition, and Medication through tools that AI agents can use naturally. Instead of learning FHIR specifications and writing custom integration code, developers can query clinical data using conversational language through MCP-compatible clients like Claude Desktop.

Key capabilities include automatic LOINC code validation to prevent AI hallucination of medical terms, intelligent document processing through vector search, and seamless integration with existing FHIR-compliant backends like Medplum or Epic.

Why It Matters for Healthcare Developers

Building healthcare applications typically means spending weeks learning FHIR documentation before writing a single line of application code. Even experienced developers struggle with medical terminology validation, OAuth2 flows for FHIR servers, and the complexity of healthcare data relationships.

The FHIR MCP Server eliminates this learning curve. Developers can focus on building clinical features instead of becoming FHIR experts. The server handles authentication complexity, prevents medical code hallucination, and provides semantic search across clinical documents - all through simple natural language queries.

his approach is particularly valuable when building AI-powered clinical tools where accuracy is critical and development speed determines market success. Unlike traditional APIs that require developers to understand complex FHIR data models where nearly all fields are optional, MCP enables AI agents to adaptively select appropriate tools and input parameters, iteratively refining their approach when encountering errors.

Use Cases for Developers

Clinical Decision Support Systems

Healthcare developers building CDSS tools can leverage patient medical histories to help clinicians make better decisions. A doctor reviewing a patient with headaches can ask an AI assistant whether any previously diagnosed conditions might be related to current symptoms.

The FHIR MCP Server automatically retrieves relevant patient conditions, analyzes medication history, and checks recent lab results to provide a complete clinical picture. This eliminates the manual process of searching through multiple EHR screens and reduces the risk of missing important clinical connections.

EHR Integration and Analytics

Development teams building analytics dashboards for healthcare organizations can use FHIR MCP Server to query clinical data without writing complex FHIR queries. Instead of having technical teams become bottlenecks for every data analysis request, clinical staff can ask questions directly.

A quality improvement team can query "Show me all patients with diabetes who haven't had an A1C test in the past 6 months" without understanding FHIR resource structures or LOINC codes. The server handles the medical terminology and returns accurate results.

Healthcare AI Applications

AI-powered healthcare tools require reliable access to structured clinical data. Developers building diagnostic support tools, treatment recommendation engines, or clinical research platforms can use FHIR MCP Server to ensure their AI models receive accurate medical data.

The server's built-in LOINC validation prevents common issues where AI models hallucinate medical codes or misinterpret clinical terminology. This accuracy is essential for healthcare applications where incorrect data interpretation can impact patient care.

Telemedicine and Remote Monitoring

Telemedicine platforms need quick access to patient histories during virtual consultations. Instead of clinicians manually searching through patient records, AI assistants powered by FHIR MCP Server can surface relevant information contextually.

A telemedicine provider can ask "What chronic conditions does this patient have and what medications are they currently taking?" The server processes the query against FHIR resources and returns structured information that helps providers make informed decisions during time-limited virtual visits.

Clinical Research and Data Analysis

Research teams conducting clinical studies often need to extract specific patient cohorts or analyze treatment outcomes across large datasets. FHIR MCP Server enables researchers to query clinical databases using natural language instead of writing complex database queries.

Researchers can ask "Find all patients diagnosed with hypertension in the last two years who are currently on ACE inhibitors" and receive accurate results without deep FHIR knowledge. This accelerates research timelines and reduces technical barriers for clinical investigators.

Healthcare Workflow Automation

Healthcare organizations building internal tools for care coordination can use FHIR MCP Server to automate routine clinical workflows. Care managers can set up automated queries to identify patients who need follow-up care or are due for preventive screenings.

The server can power notifications like "Identify diabetic patients who haven't had eye exams in 12 months" or "Find patients on blood thinners who need upcoming lab monitoring." These queries run automatically and help healthcare teams stay proactive about patient care.

When FHIR MCP Server Adds Value

FHIR MCP Server is most valuable when you're building healthcare applications that need to integrate with existing clinical systems, require medical terminology accuracy, or want to provide AI-powered clinical insights. It's particularly useful for teams that want to prototype healthcare AI features quickly without investing months in FHIR learning.

The server works best for applications where clinical accuracy is critical, integration with EHR systems is required, or where non-technical healthcare staff need to query clinical data directly. It's designed for scenarios where generic AI tools aren't sufficient because healthcare-specific validation and terminology are essential. Traditional API endpoints often fall short in healthcare scenarios due to FHIR's complexity - making it an ideal use case for MCP's adaptive, AI-driven approach to data interaction.

Getting Started

The FHIR MCP Server is available on GitHub with Docker setup and works with popular FHIR backends like Medplum out of the box. The server includes comprehensive documentation, demo videos, and can be configured with Claude Desktop or any MCP-compatible client in under five minutes.

Resources:

For healthcare development teams, the server provides immediate access to clinical data through natural language interfaces, allowing teams to focus on building features that improve patient care rather than wrestling with healthcare data standards.

Apple Health Data Analysis with AI: Our Hackathon Story

Bartosz Michalak — Fri, 24 Oct 2025 05:59:29 +0000

Key Takeaways

Personal health metrics like VO2 max become truly actionable when you can ask questions about them and get AI-powered insights rather than just viewing raw numbers in an app.
The hackathon solution eliminates two major friction points: complicated setup processes and the need for manual data exports, making continuous access to Apple Health data practical for everyday users.
By connecting Apple Health data through a MCP Server connected to LLM Client, users can have natural conversations with AI assistants about their workout performance, trends, and areas for improvement.
Automation tools like n8n enable scheduled fitness summaries and coaching feedback delivered straight to your inbox, turning passive data collection into active motivation.
The project is evolving toward a complete open-source ecosystem that will support multiple wearables, local LLM models for privacy, and custom reports for trainers, making personalized fitness insights accessible to millions of smartwatch users worldwide.

Apple Health is a great source of various metrics. But what do all of these metrics mean? With each new version of iOS and WatchOS, we get more and more insights, but it's still far from ideal. I'll give you an example from my personal life.

A while back, I was reading Outlive. One chapter made the biggest impression on me. It was about VO2 max, what this metric says about our health, and what its value means for our current and future capabilities. I really love hiking, so Peter Attia couldn't have reached me with a better message. He showed what different values of VO2 max mean when it comes to fitness capabilities at different ages. The graph shows the decline of maximum oxygen uptake (VO2 max) with age for three fitness groups. You can clearly see that someone in high fitness condition (95th percentile) at age 62 has the same aerobic capacity as an average 25-year-old. Meanwhile, someone in poor condition (5th percentile) may struggle with simple activities like quickly climbing stairs already at age 45.

Source: Jayson Gifford (https://x.com/JaysonGifford/status/1537185279781482496)

So I was really curious: what's my current VO2 max? I was pretty confident about this value since I considered myself a pretty fit person. I ran quite a bit, played soccer, cycled, played squash, and walked a lot. So it couldn't be bad. But when I checked the values, it turned out my VO2 max didn't look that good at all.

I was below average. I looked at the table from the book again and realized I had to do something about it. I checked how I could increase this value. One way was interval running. I thought, why not? After all, I like running; I only needed to change the type of training.

So I added intervals to my running, and after a while, I started seeing results. I was curious, though: is my running technique and interval training good? Besides progress in VO2 max values, am I also making progress in my times? Could any of my habits (like getting relatively little sleep) be negatively affecting these values? I couldn't find answers to any of these questions directly in the app, so I started wondering what if I used LLMs to analyze my data?

That's how the idea for creating an Apple Health MCP server was born, which you can read more about here.

After a while, it turned out this solution had two main problems:

Difficulty with installation and setup, though it wasn't a problem for me personally since you only need to do it once, many friends asked me for help, and every time it took forever.
Data updates, the server relied on an export.xml file, which was the result of manually exporting data from Apple Health. In the long run, this was a really annoying process because to have current data, I had to spend about 10 minutes each time on manual export and then transfer the data to my computer.

But finally, an opportunity came up to solve these problems. That opportunity was a hackathon.

What did we do during the hackathon?

The goal was simple: solve the two problems above. My personal ambition was to “free” my data from Apple Health, make it available through an API, and then expose it to LLMs (like Claude) via an MCP server. The stretch goal was to add automation that would, for example, send a weekly summary comparing the results to the previous week.

So our architecture looked roughly like this:

Below you'll find a short description of each system component.

Mobile (export) app

The only way to have continuous access to Apple Health data is through integration with Apple HealthKit, so we needed an application. Our hackathon team didn't have a mobile developer, and there were only three of us. We determined this might be too ambitious a task for several hours. We therefore decided to use the Apple Health Export application, which enabled exporting data to external sources, including an HTTP endpoint.

Backend

The first component we needed to create was the backend. From building the Apple Health MCP, we already had experience with what data is available in Apple Health and what data models we would need. However, we made the decision that at the hackathon we would only handle workout data, omitting health metrics. The demo was supposed to focus on summarizing workout data, providing interesting insights, and motivation to keep pushing.

We based the backend on FastAPI. For this purpose, we used python-ai-kit, a boilerplate that significantly accelerates the initial steps of application development. Thanks to this, we could focus on the actual work:

creating models
exposing a webhook consuming data sent by the mobile application
exposing an endpoint returning workout data

That was really quick. With the help of generative AI (Cursor), we built all of these parts pretty fast; however, it wouldn't have been possible without knowing how Apple Health data is structured, so we could use the experience from building the Apple Health MCP Server.

The most important model was Workout:

`class Workout(Base):
tablename = "workouts"

id: Mapped[UUIDType] = mapped_column(UUID(as_uuid=True), primary_key=True)
name: Mapped[str | None] = mapped_column(String(255))
location: Mapped[str | None] = mapped_column(String(100))
start: Mapped[datetime] = mapped_column(DateTime(timezone=True))
end: Mapped[datetime] = mapped_column(DateTime(timezone=True))
duration: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))

# aggregate metrics
active_energy_burned_qty: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))
active_energy_burned_units: Mapped[str | None] = mapped_column(String(50))
distance_qty: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))
distance_units: Mapped[str | None] = mapped_column(String(50))
intensity_qty: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))
intensity_units: Mapped[str | None] = mapped_column(String(50))
humidity_qty: Mapped[Decimal | None] = mapped_column(Numeric(10, 2))
humidity_units: Mapped[str | None] = mapped_column(String(10))
temperature_qty: Mapped[Decimal | None] = mapped_column(Numeric(10, 2))
temperature_units: Mapped[str | None] = mapped_column(String(10))

# relationships
heart_rate_data: Mapped[list["HeartRateData"]] = relationship(
    back_populates="workout",
    cascade="all, delete-orphan",
    passive_deletes=True,
)
heart_rate_recovery: Mapped[list["HeartRateRecovery"]] = relationship(
    back_populates="workout",
    cascade="all, delete-orphan",
    passive_deletes=True,
)
active_energy: Mapped[list["ActiveEnergy"]] = relationship(
    back_populates="workout",
    cascade="all, delete-orphan",
    passive_deletes=True,
)`

This model captures comprehensive workout information, including:

Temporal data: workout duration and start/end times for time-series analysis.
Performance metrics: active energy burned, distance covered, workout intensity.
Environmental conditions: temperature and humidity during exercise.
Detailed heart rate insights through relationships (real-time HR data during workouts, post-workout recovery rates, and energy expenditure patterns).
Location context: indoor vs. outdoor activities.

Looking at this carefully, you'll realize it needs improvements, for example:

Lack of indexing on commonly queried fields (start/end dates, location, workout name).
No validation for data ranges (e.g., temperature, humidity, duration must be positive).
Workout type field is a string instead of an enum.
No source tracking to identify data origin (Apple Watch, iPhone, third-party apps).

However, due to hackathon time constraints, we prioritized getting a working prototype over data model polishing.

MCP Server

The next step was to create an MCP server. We again leveraged python-ai-kit, built on top of the FastMCP framework. Below you can see how this boilerplate streamlines project creation.

Since FastAPI, which we were using in our backend, exposes OpenAPI by default, we were able to ask Cursor to add two tools: get_heart_rate and get_workouts.

The logic was simple. The tools were essentially API wrappers without adding too much custom logic on top of them. However, it was a hackathon, and we simply needed a working version.

By basing the server on FastMCP, we were able to leverage deployment via fastmcp.cloud. The only thing we had to do was connect and specify the GitHub repository where the MCP server was located, and that went very quickly.

fastmcp.cloud also provides tools for debugging MCP servers and the ability to view logs, which is very useful during development.

N8N automation

Since we still had some time left, we decided to add automation in N8N.

It was pretty straightforward, which is why I love N8N. It's ideal for very fast prototyping due to many ready-made integrations.

What you can see on the diagram (from the left):

HTTP request node: it requested our backend to fetch workout data. We used query params to filter workouts only from the latest month.
AI summary node: it took the data returned by the API, then, using an OpenAI model, prepared a summary. We had quite a bit of fun creating prompts and setting the tone of voice. Some of the generated summaries weren't nice.
Summary sending by e-mail node: it's quite self-explanatory.

N8N allows you to save the flow configuration in a .json file, so it’s easy to experiment and keep a stable version safe in the repository.

Claude

To test our MCP server, we used Claude. Since the server was available online, the configuration was very straightforward.

Claude → Settings → Connectors → Add custom connector → Set name and URL → Done.

Tip: If you're using an enterprise Claude subscription, the “Add custom connector” option may be unavailable to you. Custom extensions must be activated by the organization administrator. Then it will be possible to select it from the “Browse connectors” list.

Once added, we could check if Claude could see all the needed tools

How did the solution work?

Demo time came faster than we expected. Like every team, we had three minutes to present our solution.

I started the presentation by asking Claude what it thought about my September activity. The summary was quite comprehensive and aligned with reality (I had to check in the Apple Health app because I didn't think I had worked out that many times in total).

I also asked it about the highlights.

Unfortunately, we didn't have time to construct questions to sensibly utilize the data from the MCP tool that returned heart rate data. If you look closely, not everything worked perfectly, the calorie count was incorrectly returned for some reason. It's impossible that I burned 1,740 calories during a ~7 km run. But it was a demo, and nobody noticed.

If you read the introduction of this article, you may also notice that although I also cared about analyzing my VO2 max, the summary doesn't mention it at all. That's right. As I mentioned during the backend implementation, we decided to severely limit the scope of supported data due to limited time.

Next, we presented the result of our automation created in N8N. For the demo, we decided to choose a gentler version of the coach (though still demanding).

As you can see, I have some things to improve.

Were we satisfied with our solution? Yes, we managed to ensure continuous data flow (which was previously a problem) and demonstrate that, thanks to the MCP server, our chosen LLM client has continuous access to the data. We were also very satisfied with how python-ai-kit, which we've been intensively developing recently, helped us set up both the backend and the MCP server.

The hackathon repository is available here.
You'll find all the above-described modules in it: backend, MCP server, and N8N workflow.

What's next?

The demo made quite a good impression (though we didn't win). However, for us, it was just the beginning. AI insights based on wearables data are something we've been thinking about for quite some time.

At Momentum, we also collaborated with many companies that utilized wearables data in one way or another, thanks to which we learned a lot about them. We know that time-series data analysis isn't always simple and straightforward.

We plan to develop the solution whose development we started at the hackathon. On our roadmap at this moment is:

support for all data supported by Apple Health
fixing all the known issues in the Apple Health MCP Server (issues)
creating our own open-source application that will allow users to export data but also analyze it directly on their phone
support for other wearables, such as Garmin, Fitbit, or Oura Ring
a web application that will allow browsing data and conversing with it
ability to share data with your trainer and generate custom reports for them
support for local LLM models (we know how important privacy is in healthcare)
model fine-tuning
many more

What’s more, we will build this ecosystem as an open-source solution, so we encourage you to follow our Momentum GitHub to stay informed.

The wearables market is huge. According to the latest data, there are over 450 million smartwatch users worldwide (as of the end of September 2025), and their number is growing rapidly. We believe that these users deserve the opportunity to leverage the latest technologies such as gen AI to receive personalized health and fitness insights.

We’d love for you to explore the Apple Health MCP repo, try it out with your own Apple Health exports, and share feedback or contributions. Open source works best when it’s collaborative, and this is our invitation to build the future of healthtech with us by proposing new features, participating in collaboration, and helping shape the direction of the project.

FHIR MCP Server: Empowering Healthcare with Natural Language Interfaces

Bartosz Michalak — Wed, 08 Oct 2025 07:26:23 +0000

Open-source FHIR MCP Server, a tool that enables users to work with healthcare data using natural language-removing the need for in-depth FHIR expertise and reducing mistakes such as AI-generated code errors. Built on the Model Context Protocol, it integrates with AI clients like Claude, Cursor, and other MCP-compatible platforms. The server addresses key EHR integration challenges, including medical terminology validation, regulatory compliance, and clinical data accuracy. It supports full FHIR resource operations, automatic LOINC code validation, and semantic search across medical documents. With these features, developers can create applications that let clinicians query patient histories conversationally and build clinical decision support tools efficiently. Check it out on Momentum’s GitHub.

You’ll learn:

How FHIR MCP Server streamlines healthcare data access with natural language,
Which technical capabilities are included and how they address interoperability and compliance,
Practical examples of using conversational queries and rapid app development for healthcare,
What challenges in clinical data integration it helps overcome.

Watch our demos showing real patient data analysis and clinical workflows.

Read the full article and technical details here.