Period Tracking Implementation Guide

This draft defines a deliberately small FHIR R4 exchange model for patient-generated menstrual period tracking data. The core handoff is simple: a tracking app exports recorded facts, shares them as an encrypted SMART Health Link, and a receiving app or viewer decrypts locally to render a clinician-facing summary.

The required interoperable core is Layer 0: a bleeding calendar — menstrual bleeding true/false at the source date or timestamp. Apps can add richer Layer 1 facts such as flow, symptoms, numeric pain severity, and basal body temperature when those facts are actually stored.

System at a glance

1. Model — export the app's real stored data as a Period Tracking Bundle, starting with Layer 0 bleeding facts.
2. Share — encrypt the Bundle into a SMART Health Link; the host never sees the key or plaintext.
3. View — decrypt locally and compute summaries from granular facts; no precomputed clinical summary travels in the Bundle.

Try it now

The same standardized payload can be opened by any compatible viewer or provider scanner. These sample viewers use the same generated SMART Health Link:

Reference viewer · Layer 0 summary viewer · Bleeding-first viewer

Inspect the data behind them: the longitudinal example Bundle, a synthetic seven-cycle copper-IUD case.

Start here

• Specification defines the wire model, adoption layers, profiles, packaging rules, and security requirements.
• Implementation gives the working checklist for app inventory, FHIR mapping, sharing and hosting choices, viewer behavior, testing, and journal prompts.
• Artifacts is the generated reference for profiles, terminology, examples, and machine-readable JSON.

Source repository: github.com/jmandel/cycle.

Version 0.2.0 is an implementation draft for prototyping and testing. It is not an HL7-balloted implementation guide and does not establish clinical decision rules.