We have been heads-down building since we started Clair Health, and our early access program is the first time we have opened the product to external users in a structured way. This post explains what we actually set up, how onboarding works for both individual users and fertility clinic integrations, and what we are doing with the feedback we receive. It is also an honest account of what the product can and cannot do right now.
Who the early access program is for
We opened access to two groups: individuals who want to use continuous wrist biosensor data for personal cycle tracking, and fertility clinics that want to explore integrating passive cycle phase data into their existing patient workflows. These two groups have genuinely different needs, and the onboarding process differs accordingly.
For individual users: the primary requirement is an existing compatible wrist biosensor that logs skin temperature continuously and exports raw or processed data. We currently support data exports from the main consumer devices that provide this functionality. You do not need a new device. The product is software and inference, not hardware.
For fertility clinics: we are working with small clinical practices (typically two to six providers) that are willing to engage with an early-stage product and provide structured feedback. This is not a passive installation. We expect regular check-ins, case-level feedback, and engagement from at least one clinician on the practice side who will actually look at the data with patients. Practices that want a hands-off integration and will evaluate the product by outcome metrics alone six months later are not the right fit for this phase.
Onboarding: individual users
Individual user onboarding has three steps. First, you create an account and connect your biosensor data source. We use a read-only API connection or a manual export upload depending on what the device supports. No health record data is transmitted; only the wearable sensor stream.
Second, there is a 21-day baseline collection period before phase inference begins. During this window, the model is learning your personal circadian temperature pattern, your resting HRV baseline, and your movement profile. The app is visible during this period; it just shows the raw incoming signals rather than a phase estimate. We found in early testing that showing a phase estimate before the baseline is established produces a worse experience than showing the raw data clearly labeled as "baseline collection in progress." Users who understood what was happening were more patient with the initialization than users who were shown an early, low-confidence estimate without that context.
Third, once baseline collection completes, you start receiving daily phase state outputs with confidence intervals. The interface shows you the most likely phase state, the probability distribution across all four states, and how confident the model is today based on signal quality and baseline stability. If you wore the device less than 14 hours yesterday, the confidence interval expands and you see a note explaining why.
The app does not tell you what to do with the information. It does not give recommendations about timing intercourse for conception or contraception. It is a data display product, not a clinical decision tool. What you do with the phase information is your business.
Onboarding: fertility clinic integrations
Clinic onboarding is more involved and takes four to six weeks from initial contact to the first patient seeing data. The main steps are a technical integration meeting to review data flows, a pilot agreement that covers data use and aligns with HIPAA-aligned data handling practices, device setup for enrolled patients, and a 30-day clinical review checkpoint where we look at the data together with the participating clinician before expanding to more patients.
One thing we have been explicit about from the start: the phase inference output is a supplementary data stream, not a replacement for any existing clinical assessment. We do not want clinicians to stop ordering CD3 bloodwork or ultrasound monitoring and substitute our wrist data for it. The value is in having a richer temporal picture of what a patient's cycle looks like between visits, not in replacing any specific lab or imaging touchpoint.
The integration currently surfaces as a simple patient data view accessible through the clinic's dashboard. We are not integrated into EMR systems yet. The data is visible in a Clair Health portal that the clinic accesses for enrolled patients. Full EMR integration is on our roadmap but is not a blocking requirement for the early access program.
What data flows you get
Individual users receive: daily phase state probability vectors, confidence intervals, and a 30-day calendar view showing phase progression over their recent history. For clinic integrations, the same data is available for each enrolled patient plus a cycle summary view that shows the phase timeline, signal quality flags, and any days where data coverage was low enough that the model reduced its output confidence.
We surface signal quality flags because they are meaningful clinical information. If a patient's biosensor data shows consistent 8-hour wear windows rather than 18-hour windows, the inference quality is lower and a clinician should weight that accordingly. We do not want anyone making decisions based on a confident-looking output that is actually built on sparse data.
We do not currently provide: ovulation day predictions with clinical precision, cycle length forecasting, or fertility window scoring. Those outputs require a higher confidence in phase boundary timing than we can consistently deliver at this stage. We will add them when we can deliver them with appropriate uncertainty bounds, not before.
How feedback shapes the roadmap
The feedback that has been most useful falls into two categories. The first is cases where the model's phase output diverges noticeably from what the user or clinician expected, with some additional context about why the expectation existed. A message that says "the app showed follicular on day 18 but my OPK was positive and temperature shifted the next day" is actionable. It tells us the model was late on the periovulatory detection, and we can look at that person's signal around that time to understand why.
The second category is UX friction reports. Cases where users were confused about what a confidence interval meant, or where a clinic coordinator spent time trying to find information that was two clicks away from where they expected it. We track these separately from model-performance feedback because they require different fixes.
We read every piece of structured feedback and most of the unstructured messages. We are a three-person team, and the person who built the feature usually reads the feedback about it. That is not going to scale forever, but for this phase it is the right way to stay connected to how the product is actually being used versus how we assumed it would be used.
If you are interested in joining the early access program, the application is at the link below. We review applications in batches and prioritize users with regular cycle patterns for individual access (because the model performs more reliably on those patterns right now) and practices that are already interested in passive monitoring approaches for fertility clinic access.