Transforming Doctor Visits by Feeding Health Data to AI: Personal Healthcare Platform with Claude Skills and Cloudflare

1. Introduction: The Problem of Not Being Able to Answer "How Was Your Last Month?"

To be personal, I suffer from lifestyle-related diseases and Sleep Apnea Syndrome (SAS), requiring me to visit several medical departments once or twice a month. The metrics I need to manage are extensive: weight, blood pressure, blood test results (HbA1c, LDL, TG, UA...), CPAP usage, sleep duration, step counts, and dietary intake.

Every time I visit the hospital, I am asked, "How has your last month been?"

Answering this clearly is difficult.
In a professional setting, I would summarize the materials in advance, visualize the necessary data, and project it using remote meeting tools to explain it.

However, I cannot do that at the hospital.

The problem was not that I wasn't recording things; it was that I had records but couldn't communicate them. The paper results of past blood tests, data displayed on the CPAP screen, apps for my body composition monitor and blood pressure monitor, and Google Fit—the data was scattered across different silos. I had no means to view "the overall picture of the last month" from a single perspective. It wasn't formatted in a way I could hand to a doctor, either. In the end, ambiguous, conversation-based exchanges were repeated in the exam room.

What I wanted was a system that could aggregate scattered health data into one place, allowing me to demonstrate "how last month went" with data at every visit. Furthermore, I wanted an experience where I could "interact with the data"—getting feedback after reporting meals, or checking the room environment before bed.

In this article, I will introduce the personal healthcare infrastructure I built to solve this challenge.
The overall system architecture is as follows.

The basic flow is to collect data from the devices and apps on the left, store it in Cloudflare Workers + D1 in the center, and have Claude Skills on the right read and analyze the data to output daily feedback and clinic reports.

2. System Architecture Overview

Looking at the diagram in Chapter 1 again, this system is divided into three main layers.

1. Data Collection & Storage Layer: Aggregates health data from devices/apps and stores it in Cloudflare Workers + D1.
2. AI Interpretation Layer: Claude Skills calls APIs to retrieve data for analysis, estimation, and report generation (and some data recording).
3. Output Layer: Returns information to the human as clinic reports, daily feedback, and nutrition charts.

In this chapter, I will outline the design decisions for each layer, and delve into individual implementation details from Chapter 3 onwards.

Data Collection & Storage Layer

health-sync-api (Cloudflare Workers + D1)

A REST API that acts as the central store for health data. The source code is available at GitHub: kiakiraki/health-sync-api.

I chose Cloudflare Workers + D1 for the tech stack because the operating cost for a personal project is effectively zero. The free tier for Workers is 100,000 requests per day, and D1 provides 5GB for free. This is more than enough for the traffic generated by personal health data.

The endpoints consist of the following five categories:

Endpoint	Method	Role
/metrics	GET	Batch retrieval of weight, BP, sleep, steps, and CPAP
/blood-test	GET / POST	Retrieval/recording of blood test data
/meals	GET / POST	Retrieval/recording of meal data
/cpap	POST	Recording of CPAP data
/health	GET	Health check

health-sync-app (Android)

An Android app that retrieves body composition, blood pressure, step, and sleep data from Google Fit (Health Connect) and POSTs it to health-sync-api. The source code is available at GitHub: kiakiraki/health-sync-app.

I chose a native app here simply because an Android app is required to access the Health Connect API. Body monitors (weight/body fat) and blood pressure monitors record to the smartphone via Bluetooth and aggregate into Health Connect. This app acts as a pipeline to pull data from there and transfer it to my own API.

location-sync-api

A location data storage and search API. It supports importing Google Location History and real-time location recording from the OwnTracks app. I wrote about the design and implementation of this component in detail in a previous article.

👉 I Made a Skill That Lets AI Stalk My Location (Zenn)

In this article, I won't touch on the details of location information, but will treat it as a context source for Claude Skills to reference "where I am now" or "recent activity patterns."

SwitchBot CO2 Sensor

I retrieve temperature, humidity, and CO2 levels in real-time from a SwitchBot MeterPro (CO2) installed in my room. This is not stored in my own DB; instead, the Claude Skill directly calls the SwitchBot API v1.1 each time.

Its primary use is for environment checks before going to sleep. I've incorporated it into a flow for "checking the room state before bed."

AI Interpretation Layer

This is the core of the system, which I will explain in detail in Chapter 4. Briefly, I use Claude's custom skill feature (Claude Skills) and have defined five Skills for the APIs mentioned above.

Skill	Role
health-sync	Metrics retrieval, reference value judgment, trend analysis, medication efficacy evaluation
nutrition-tracker	Meal recording from conversation, nutrient estimation, visualization
health-report	Clinic report generation (supports monochrome printing)
switchbot-env	Real-time indoor environment acquisition/judgment
location-sync	Location context acquisition

What is important is that I have positioned AI not as a layer for collecting data, but as a layer for interpreting data and returning it to humans. Data collection and storage are handled by Cloudflare Workers and the Android app, while Claude focuses on the role of "reading, thinking, and communicating" that data. With this separation, changes on the Skill side (adding analysis logic, updating reference values) do not affect the data layer, and conversely, changes to the API schema can be absorbed simply by rewriting the Skill's text.

Output Layer

There are three main types of output.

Clinic Reports. If I say "make this month's report," a report for printing is generated in React (.jsx) after cross-analyzing all data. The design assumes printing on a monochrome printer, and graph line types are distinguished by solid/dashed lines and shading. I print this and hand it to the doctor during the consultation.

Daily Feedback. If I report my meals, I get comments on nutritional balance; if I ask for an environment check before bed, I get judgments on CO2 and humidity. Since data is recorded to the API in the background, it is reflected in the report later.

Nutrition Charts. At the timing when I finish reporting my daily meals, I can visualize my nutritional balance with radar or bar charts. This is output as a React component using Recharts.

3. Data Collection Layer

I provided an overview of the architecture in Chapter 2. In this chapter, I will delve into "where the data comes from and how it gets in."

There are five main data input channels for this system:

Input Channel	Target Data	Method
Android App → API	Weight, Body Fat, BP, Steps, Sleep	Auto-sync from Health Connect
Chat with Claude → API	Meal contents, CPAP data	Reported via chat → Claude estimates nutrition/structures → POST
Images → Claude → API	Blood test results	Photograph results → Claude performs OCR → POST
SwitchBot API	Room temp, humidity, CO2	Claude Skill retrieves in real-time (no storage)
OwnTracks → API	Location data	Auto-recorded via Webhook

Interestingly, two of these five channels are "data input via the conversation with Claude itself." In traditional healthcare apps, users had to choose between manual form entry or automatic device synchronization. Here, I have a third option: "talking to the AI."

3.1 Automatic Synchronization via Health Connect

Data measured by body composition monitors or blood pressure monitors is recorded to the smartphone via Bluetooth and aggregated into Android's Health Connect. The health-sync-app acts as a pipeline that reads this data from Health Connect and POSTs it to health-sync-api.

Synchronization targets are the following four types:

Health Connect Data Type	API Storage Destination
WeightRecord / BodyFatRecord	body_measurements table
BloodPressureRecord	blood_pressure table
StepsRecord	steps table
SleepSessionRecord	sleep_sessions table

The synchronization trigger is currently manual, but I am considering future background synchronization.

3.2 Data Input via Conversation: Meals and CPAP

The most unique aspect of this system is that everyday conversations with Claude become data input.

Meal Recording

For example, if I tell Claude, "For lunch, I had a FamilyMart chicken soboro bento and miso soup," the following happens in the background:

1. Claude parses the meal content and extracts the date, meal timing (lunch), and menu.
2. Claude estimates nutrients (calories, protein, fat, carbohydrates, dietary fiber, salt) based on its knowledge base.
3. Structured JSON is sent to the API via POST /meals.
4. It conveys that the record is complete and provides simple feedback (e.g., "That might be a bit high in salt").

{
  "date": "2026-02-13",
  "meal_type": "lunch",
  "description": "FamilyMart chicken soboro bento, miso soup",
  "calories_kcal": 650,
  "protein_g": 25,
  "fat_g": 18,
  "carbs_g": 90,
  "fiber_g": 3,
  "salt_g": 3.5,
  "note": "Convenience store meal"
}

Traditional meal recording apps required steps like searching for the menu, selecting it, and entering portions. Here, all I need to do is "tell it what I ate in Japanese." The accuracy of nutrient estimation depends on the LLM's knowledge base and is not as precise as values calculated by a nutritionist. However, the most important factor in meal recording is continuity over precision. A record that remains consistent—even if slightly rough—is far more useful for trend analysis than a perfect record that stops being updated.

CPAP Data

CPAP data is reported in the same way via conversation. If I say, "Yesterday's CPAP, AHI 3.2, 6.5 hours used, leak 4.2," Claude structures it and sends it to POST /cpap. The CPAP device I use has no synchronization method, and I have no choice but to read the numbers from the screen, making manual reporting the only realistic option. A conversation format allows me to complete this in one line, making it easy to incorporate into my morning routine.

3.3 Data Input via Image OCR: Blood Tests

For blood test results, I scan the paper result sheet received from the clinic using ScanSnap and provide it as an image to Claude. Claude reads each item using OCR, structures it, and sends it to POST /blood-test.

{
  "test_date": "2026-02-01",
  "facility": "XX Clinic",
  "hba1c": 6.2,
  "ldl": 128,
  "hdl": 52,
  "tg": 145,
  "ua": 6.8,
  "ast": 22,
  "alt": 28,
  "gtp": 35,
  "cr": 0.9,
  "egfr": 72,
  "glucose": 105
}

Since this happens about once a month, automation is not necessary, and the convenience lies in simply handing over the image and saying "Record this." Manually entering many items is a hassle, but OCR allows me to read all items in one go.

3.4 DB Schema Design

The health-sync-api D1 database contains the following tables:

Table	Primary Key / Unique Constraint	Key Columns
body_measurements	id (auto)	recorded_at, weight_kg, body_fat_percent
blood_pressure	id (auto)	recorded_at, systolic, diastolic, pulse
sleep_sessions	id (auto)	start_time, end_time, duration_hours
steps	id (auto)	date, count
cpap_logs	recorded_date (upsert)	ahi, ai, leak, usage_hours, pressure_stats, breathing_stats
meals	date + meal_type (upsert)	description, calories_kcal, PFC, fiber_g, salt_g
blood_tests	test_date (upsert)	facility, hba1c, ldl, hdl, tg, ua, etc.

In my design, I focused on the granularity of upserts. CPAP is one record per day, meals are one record per day/timing, and blood tests are one record per test date. Since each record is "overwritten if re-submitted with the same key," correction and addition are easy. If I report a meal and then add "Oh, I also had a salad," Claude adds that to the description of the existing record and re-POSTs it—this also works naturally thanks to upserts.

4. AI Interpretation Layer

Up until the previous chapter, we looked at the mechanisms for data collection and accumulation. In this chapter, I will delve into the design and implementation of the AI layer that "reads, thinks, and communicates" the collected data: Claude Skills.

4.1 What are Claude Skills?

Claude Skills are a mechanism for giving Claude custom knowledge and workflows on claude.ai. You describe information that Claude should refer to (API specifications, judgment criteria, workflow definitions, etc.) in a Markdown file called SKILL.md and upload it. Claude automatically refers to the appropriate Skill depending on the context of the conversation and operates according to the procedures written there.

While the concept is close to system prompts or RAG, the feature that makes Skills unique is their ability to be combined with code execution environments (bash, file creation, etc.). It can complete complex tasks—such as hitting an API to fetch data, analyzing it, and generating a report with graphs—within a single conversation.

For the basic mechanism and creation methods of Skills, please refer to the official documentation.

• What are Skills? Using Skills in Claude（Claude Help Center）
• How to create custom Skills（Claude Help Center）

In this article, I will focus on the practical aspect of "how I used them for health data management."

4.2 Skill = An Operational Manual for AI to Read

In this system, I have defined five Skills. I designed each Skill not just as an API specification, but as an "operational manual for AI to read."

Specifically, I have compiled the following information into each Skill:

Content Description	Example
API Specifications	Endpoints, Request/Response formats, Authentication info
Domain Knowledge	Blood pressure classification criteria, normal ranges for each blood test item
User Context	Medication list, target diseases, weight goals, characteristics of the CPAP model
Judgment Logic	"AHI < 5 is good," "If BP is above this value, it's hypertensive range"
Workflow	"When generating a hospital report, fetch /metrics and /meals from the same period..."
Output Specifications	Graph design system, colors, fonts, print CSS

In a traditional approach, you would likely implement judgment logic as code in the backend, build the UI in the frontend, and manage domain knowledge separately as documentation. Here, I have taken the approach of writing all of these in text and passing them to the AI's context.

4.3 Roles and Design of the 5 Skills

health-sync Skill: Foundation for Data Retrieval and Analysis

This is the most basic Skill, containing the full API specification and response schema for health-sync-api. On its own, it can handle analysis queries like "Show me weight trends for the past week" or "What is the trend for blood pressure last month?"

The key to this Skill is that it holds analysis guidelines in text form.

### Analysis Points
1. Trend-focused: Emphasize moving averages and weekly trends over single-day values.
2. Correlation Analysis: Sleep duration vs. CPAP usage time, BP vs. sleep quality, etc.
3. Drug Efficacy Evaluation: Track therapeutic effects through chronological changes in blood tests.
4. Impact of Drug X: Started on YYYY-MM-DD. Track trends in related metrics before and after start.

By writing down the policy of "what and how to analyze" in the Skill, Claude can read and interpret data from a consistent perspective without requiring instructions in every prompt.

Another important element is the medication start date table.

| Medication | Start Date | Remarks |
|------|--------|------|
| Drug X (Type) | 20XX-XX-XX | Explanation of expected effects |

By writing this down, Claude automatically checks for "changes since this date" during trend analysis. Every time a new medication is added, I just add one line here.

nutrition-tracker Skill: Turning Conversations into Data

A Skill responsible for meal recording, nutritional estimation, and visualization. Its design feature is the automatic determination of three modes.

Mode	Trigger	Action
Recording	"Had lunch" etc.	Estimate nutrients from chat → POST to API
Visualization	"Show me nutritional balance" etc.	Generate React component for radar chart
Report	"Review this month's meals" etc.	Aggregate by period → Generate report with trend charts

Mode determination is written in the Skill text based on keywords. If it contains "summary," "chart," "graph," "visualization," "balance," or "missing," it triggers visualization mode; if it contains "clinic," "report," or "review," it triggers report mode; otherwise, if meal contents are included, it triggers recording mode.

Nutritional estimation relies on Claude's knowledge base. For a "FamilyMart chicken soboro bento," it estimates calories, PFC (protein, fat, carbohydrate), dietary fiber, and salt equivalent. Since this is not a reference to an accurate nutritional database, there are errors, but as mentioned in Chapter 3, it is a choice of "continuity over precision."

health-report Skill: Automatic Generation of Hospital Reports

This is the Skill responsible for the final output of this system and contains the most descriptive text. If I say "Generate this month's report," it fetches all data from health-sync-api and generates a React (.jsx) report optimized for monochrome printing.

A complete design system is described in the Skill.

## Color Palette (Grayscale)
const mono = {
  black:  "#1a1a1a",  // Title, Main lines
  dark:   "#333333",  // Section titles
  mid:    "#666666",  // Sub-text, Baseline
  light:  "#999999",  // Captions
  pale:   "#cccccc",  // Light bars
  faint:  "#e5e5e5",  // Table borders
};

Why monochrome? Because the printer I use at home is a monochrome laser printer. It's for practical reasons, but there are secondary benefits: information isn't lost if copied at a clinic, and visibility on monitors remains stable in grayscale. Line graph styles are distinguished in four levels (solid, dashed, dotted, dot-dashed), and bar graphs represent normal/abnormal through shades. By informing the AI of these printing constraints, it outputs in a consistent design without needing to be told "in monochrome" every time.

Report structure consists of 10 sections. It covers weight, blood pressure, CPAP, sleep, steps, nutrition, meal patterns, and blood tests, with a summary and alerts (▶Action required / △Caution / ○Good / ◇Info) at the top. Auto-generation rules for alerts are also defined in the Skill; for example, "Day without CPAP usage → ▶Action required," "Weight gain trend → △Caution," "Average AHI < 5 → ○Good."

switchbot-env Skill: Real-time Retrieval of Indoor Environment

A Skill that hits the SwitchBot API v1.1 to retrieve indoor temperature, humidity, and CO2 levels. Unlike other Skills, there is no storage in a private DB; it is a real-time retrieval configuration.

Judgment criteria are written in the Skill. For CO2, "400–700ppm: Good," "1001–1500ppm: Slightly high, ventilation recommended." Furthermore, it defines the ideal environment for sleep as "18–22°C, 40–60% humidity, CO2 below 700ppm," allowing for checks specialized for bedtime.

location-sync Skill: Location Context

I wrote in detail about the use of location data in my previous article, so I will focus on its use in the healthcare context here.

This Skill is mainly used for estimating behavioral patterns. Days with fewer than 3,000 steps can be estimated as "days at home," but the confidence improves with location data. Location data acts as auxiliary context for analysis, such as whether there is a difference in blood pressure or sleep trends between days when I commuted and days I didn't.

4.4 Collaboration Between Skills

The five Skills run independently, but only the health-report Skill is designed to explicitly refer to the other two.

## Dependent Skills
| Skill | Reference Content |
|--------|----------|
| health-sync | API endpoints, reference values, analysis guidelines |
| nutrition-tracker | Meal data aggregation logic, handling rules for missing values |

Since the hospital report handles all data cross-sectionally, it references the health-sync Skill for API specifications and the nutrition-tracker Skill for meal missing-value handling rules (e.g., "If breakfast is missing, fill with the average of the last 5 days"). If you write "refer to this Skill" in the Skill text, Claude will read those Skills too during report generation and perform consistent processing.

4.5 Limitations of this Design

Since I've only listed the merits, I will honestly write about the limitations too.

Consumption of Context Window: The content of the Skills is expanded into the context for each conversation. Combining all five Skills results in a significant number of tokens. That said, not all Skills are expanded at once; only those necessary depending on the content of the conversation are referenced.

No Guarantee of Reproducibility: Even if you ask for the same analysis on the same data, the output will not be exactly the same. Given the nature of LLMs, this is unavoidable. The layout of hospital reports varies slightly each time, and nutritional estimates also fluctuate. I operate at a level of reproducibility where "analysis in roughly the same direction is produced."

Problem of overly long Skills: The health-report Skill becomes quite long when the design system is included. I may need to decide in the future whether to split the Skills or offload some to the code execution side.

5. Actual Operational Workflow

Having explained the mechanisms in the previous chapters, let's look at how I actually use it every day—the concrete operational workflow.

5.1 Daily Routine: Reporting Meals

The most frequent operation is reporting meals. I tell Claude what I ate at breakfast, lunch, and dinner.

User: For lunch, I had a FamilyMart chicken soboro bento and miso soup.

With just this, Claude estimates the nutrients, records them to the API, and returns a simple piece of feedback.

Claude: Logged. 
  Approx. 650kcal / Protein 25g / Fat 18g / Carbohydrates 90g / Salt 3.5g
  The salt content is a bit high. It might be good to be mindful of bland flavors for dinner.

Once I have finished reporting my meals for the day, saying "Show me today's nutritional balance" will visualize the achievement rate with a radar chart. You can see at a glance the level of achievement against goals across six axes: protein, fat, carbohydrates, dietary fiber, vitamins, and minerals.

The key point of this workflow is that recording exists as an extension of conversation. Rather than "opening a recording app, selecting a menu, and...", simply saying "I ate X for lunch" during casual chat logs it. This low hurdle is the biggest factor in my continued usage.

5.2 Every Morning Routine: Reporting CPAP Data

After waking up, I check the previous night's data on the CPAP device app and report it to Claude.

User: Yesterday's CPAP, AHI 3.2, usage 6.5 hours, leak 4.2

Claude structures the values, records them to the API, and adds a simple assessment. If the AHI exceeds the reference value, it points it out, and it makes me aware if the usage time is short.

While this report is manual, it fits naturally into my morning habit as it only takes one line. If the CPAP device manufacturer were to open an API, I could automate this part, but since there is currently no such means, conversational input is the practical solution.

5.3 Before Bedtime: Environmental Check

When I ask "What's the room environment like right now?" before going to sleep, Claude hits the SwitchBot API to fetch the room temperature, humidity, and CO2, and returns the judgment results.

Claude: Room temp 22.5℃ (comfortable), humidity 38% (slightly dry), CO2 850ppm (normal).
  Humidity is a bit low. I think turning on the humidifier before sleeping
  can reduce dryness caused by CPAP.

This workflow is not an analysis of stored data but a judgment based on real-time sensor values. I do not store SwitchBot data in my own DB, so I cannot compare it with the past. However, real-time values are sufficient for decision-making before sleep (whether to turn on the humidifier or open a window).

5.4 Before Hospital Visits: Report Generation

Before a hospital visit (once or twice a month), I ask Claude to "Create this month's report."

Claude generates the report following this flow:

1. Fetches metrics for the current month from health-sync-api (weight, BP, sleep, steps, CPAP).
2. Fetches meal data for the same period.
3. Fetches the full history of blood tests.
4. Analyzes all data cross-sectionally and generates a report in React (.jsx).

The output report is 3–4 pages in A4 size. It has a summary table and alert list (▶Action required / △Caution / ○Good / ◇Info) at the beginning, followed by weight trends, BP trends, CPAP usage, sleep duration, steps, nutritional balance, meal pattern analysis, and blood test trends.

Report Structure:
  Header (Period, Medication list)
  → Summary (List of key indicators)
  → Alerts (▶Action required / △Caution / ○Good / ◇Info)
  → Graphs and tables for each section
  → Footer (Notes, generation timestamp)

I print this on my home printer and hand it to the doctor during the consultation.

Because of this report, when asked "How was it last month?", I can talk concretely while showing the data, saying things like "Weight followed this trend, blood pressure tended to be slightly higher in the latter half, and salt intake in meals was high during this week." The doctor can also engage in deeper discussions while looking at the graphs, such as "This change here might mean the medication is starting to take effect."

5.5 Evaluating Drug Efficacy: Automatic Before/After Comparison

When a new medication is prescribed, I add the drug name and start date to the Skill in one line.

| Medication | Start Date | Remarks |
|------|--------|------|
| Drug X | 20XX-XX-XX | Expected effects |

From then on, Claude becomes mindful of comparing "Before vs. After" using this date as a boundary during analysis. When asked about trends in weight or blood test values, evaluations like "This value is showing an improvement trend since the start" or "Changes are not yet visible" come up naturally.

It also appears in the hospital report as "◇Info: Drug X Started (20XX-XX-XX)" in the alerts, so the doctor can grasp "when I started taking it" at a glance.

5.6 Irregular: Entering Blood Test Results

About once a month, after getting blood tests at the clinic, I receive the paper results. I scan this with ScanSnap and pass it to Claude as an image.

User: [Image of result sheet] Log this.

Claude reads the values for each item from the image, structures them, and POSTs them to the API. It's tedious to enter manually because there are many items (over 10), but bulk reading from an image takes only one shot. Since it displays the reading results for confirmation, I can correct it on the spot if there is an OCR error.

5.7 Summary of the Flow

Summarizing the daily operations:

Timing	Operation	Time Required
After each meal	Report what I ate to Claude	30 sec
Every morning	Report CPAP data in one line	15 sec
Before bed	Ask "How's the room environment?"	10 sec
Before hospital	Ask to "Create this month's report"	3-4 min wait
Once a month	Scan and pass blood test result sheet	3 min

The daily operations take only a few minutes in total. This simplicity is the key to continuity; conversely, if this becomes a hassle, the system fails. "Do not do anything unnecessary for recording" is the basic design policy.

6. Challenges in Design

Precision of Nutritional Estimation

This is the point I was most consciously willing to compromise on.

Nutritional estimation of meals depends on Claude's knowledge base and naturally deviates from values calculated by a nutritionist looking up a food composition table. The calories of a "FamilyMart chicken soboro bento" will likely differ from the actual package label by several dozen kcal.

Still, the reason I chose this method is that I judged that the implementation cost of linking to a nutritional database would kill continuity. If I build a system to prepare a food DB, match menus, normalize amounts, and so on, recording would stop at "menus not in the DB" or "eating out with unknown portions." A system that works roughly well overall is better for long-term trend analysis than a system that fails in specific parts.

As a real-world experience, trends in PFC balance (weeks with insufficient protein, weeks with high salt) are sufficiently visible even with LLM estimation. Being able to capture relative day-to-day changes was more important than the accuracy of individual values.

Absence of Reproducibility

If you generate a hospital report for the same period twice, the graph layout and alert wording will be slightly different. As long as it is an LLM-based system, this is unavoidable.

However, it did not cause a problem in practice. There are two reasons. One is that generating the report is a one-time event right before the hospital visit, so there is no use case for "comparing it with the previous one." The other is that the direction of analysis (which indicators to focus on, what thresholds to set) is written in the Skill, so the deviation at the conclusion level is small. Even if the wording or layout changes, judgments like "weight is on an increasing trend" or "AHI is good" remain stable.

However, this is a judgment I could tolerate because the use case is a "hospital report." For use cases requiring output identity, such as regulatory reporting or insurance claims, this approach is not suitable.

Bloat of Skills

The health-report Skill includes everything from report structure, design system (color palette, typography, graph settings), alert generation rules, to print CSS, all written in text. As a result, one file is quite long.

Ideally, I should separate the design system part as code and write only "use this code" in the Skill. But currently, the practical benefit that "it's easier to change if you write everything in the Skill text" wins.

This judgment is valid because the scale of the system is small. If the number of Skills increases to 10 or 20, or if it starts being operated by multiple people, a migration to a structured codebase will become necessary.

Handling Missing Data

Although it assumes daily recording, there are naturally days I forget. Meal data, in particular, is prone to being forgotten on busy days or when out. There is also the issue of how to handle past data before recording started.

In conclusion, I adopted a method of filling in with the latest similar data. Days without breakfast, lunch, or dinner records are filled with the average of the same meal timing over the last 5 days. However, I have clearly stated in the Skill the rule to visually distinguish that it is supplementary data (e.g., using dotted lines or gray on charts).
It's not perfect, but being able to "use it even without 100% recording rate" was important for continuity.

Security

Health data is sensitive information. However, the data is stored in Cloudflare D1 and is not sent to third-party healthcare platforms. Since data flows through conversations with Claude, it is handled within the scope of Anthropic's privacy policy.

I have not implemented full-scale security measures like audit logs. I have accepted this because this is a system used by an individual for themselves. If I were to release it as a service that handles other people's data, this design would be insufficient.

Privacy

This system passes a fairly wide range of personal data to Claude, including weight, blood pressure, meal contents, sleep patterns, and location data. As the title "Passing All My Data to AI" suggests.

Whether to tolerate this is an individual judgment, but in my case, the criterion was that I have control over the data management. Data is saved in my own D1, and I also manage the API endpoints. I pass data to Claude on a case-by-case basis, but what is accumulated is my own DB, not entrusting data to a third-party service.

Nevertheless, it is a fact that data passes through Anthropic's infrastructure through conversations with Claude. This risk cannot be reduced to zero. This is also a compromise of "what I can tolerate within the scope of personal use."

Summary: Common Points of Compromise

Looking back, there are commonalities in the compromise patterns.

Prioritized "continuity" over "correctness." Nutritional estimation precision, reproducibility, missing data handling—theoretically, there are more accurate ways for all of them. But there is no point if you pursue accuracy, the mechanism becomes complex, and you stop using it.

Defined the scope of "personal use." Security and privacy are also drawn based on the premise of "I use my own data." If I go beyond this scope (handling other people's data, providing it as a service), I would need to redo many of the judgments.

Conclusion

In this article, I introduced the personal healthcare infrastructure built for managing lifestyle-related diseases and SAS.

In a word, I built a mechanism to collect scattered health data into a single API, interpret it with Claude Skills, and output it as a hospital report. The technologies used—Cloudflare Workers, D1, Android Health Connect, Claude Skills—are nothing special.

Even so, the hospital experience is completely different with or without this mechanism. When asked "How was it last month?", I can answer with data, not memory. Conversations with the doctor change from "somehow" to "concrete." This was the initial motivation, and it has been achieved at this point.