Visit summary & data exports

Clinician visit summary

Generate a clean, one-page visit summary of your labs, medications, recent symptoms, and the questions worth raising. Print it directly from Ojava (choose “Save as PDF” in your browser’s print dialog) or share a read-only link. It is a record-organization aid for a clinician conversation, not a medical record, diagnosis, or treatment recommendation; your clinician interprets the results and decides on any care.

Shareable read-only link

Create an unguessable, expiring link to a read-only snapshot of your summary. Anyone with the link can view that summary for up to 7 days, after which it expires automatically. You can send it to a clinician, family member, or another provider without giving them access to your account, and you can revoke it by letting it expire. The link contains only an opaque token; your health data is never embedded in the URL.

Email the link to yourself

You can email the secure link to your own account email so you can forward it or keep it handy. For safety, email only ever goes to your signed-in account address (never an arbitrary recipient), and it carries only the tokenized link, never your health data.

FHIR health-data export

Export your accepted health data as a standard FHIR R4 JSON file, the interoperability format other health apps, clinicians, and electronic health record systems can read. It includes the labs, medications, allergy and intolerance history, immunization history, and other observations you have reviewed and confirmed, so your data is portable and not locked into Ojava. Accepted imported FHIR immunization rows are emitted as FHIR Immunization resources when enough source detail exists, accepted imported FHIR and C-CDA allergy rows plus allergies the user saved directly are emitted as FHIR AllergyIntolerance resources, and accepted clinical-history rows can export as local Encounter,Condition, Procedure, MedicationDispense,MedicationAdministration, ServiceRequest, CarePlan,Goal, FamilyMemberHistory, metadata-only RelatedPerson, metadata-only Device, metadata-only Specimen, and metadata-only DocumentReference resources. They are user-reviewed portability only, not a decision that a condition is diagnosed, a vaccine is needed, family history proves risk, a genetic test or screening is needed, an allergy is clinically valid, a caregiver relationship is verified, an emergency contact has been shared, a device has been paired, live sync is active, a device feed is monitored, an alert has been sent, hardware can be controlled, a medical device is validated, recall or warranty advice is given, a specimen is adequate, a lab result is validated, retesting is advised, collection instructions are provided, a procedure or referral is complete, medication was fulfilled, medication was administered, adherence was proven, a document attachment was interpreted, or care is recommended or prescribed.

The standalone FHIR file also includes one export-local FHIR Provenance resource when exported FHIR resources exist. It targets the local resources in that file and records the export timestamp, transform version, and generic source-trail labels. It does not expose raw filenames, source-file ids, import ids, provider identifiers, or attachment metadata, and it does not validate source correctness, identity, clinical meaning, legal attestation, diagnosis, monitoring, coverage, or care recommendations.

Health data package

From Settings, you can also download one health data package JSON file. It includes a manifest, the FHIR bundle, a canonical event ledger, source-quality and source-feed review details, a longitudinal source profile, field and coding coverage, a source unit-normalization profile, source identity attribution, source identity consistency checks, source-priority policy, source-cohort transparency, a source-normalization release packet, a source-repair plan, a tracker-event ledger for food, workouts, wearables, symptoms, and mood, the user’s active allergy list and saved history notes, a sanitized record-network lifecycle ledger for connected provider-record sources, a sanitized wearable lifecycle ledger for native health and connected wearable sources, a machine-readable data dictionary for every package artifact, and recent audit history. It is useful when you want the record plus the provenance story behind it, not just the final accepted values.

The included FHIR bundle carries accepted labs, vitals, medications, accepted imported immunization-history resources, accepted imported FHIR or C-CDA allergy or intolerance resources, accepted encounter, appointment, condition, procedure, medication-dispense, medication-administration, service-request, care-plan, goal, family-member-history, metadata-only related-person, metadata-only source-device, metadata-only specimen, and metadata-only document-reference resources, generic package-local tracker Observation resources for scalar food, workout, wearable, symptom, and mood metrics, and one package-local FHIR Provenance resource when exported FHIR resources exist. ThatProvenance entry targets the package’s own FHIR resources and records the export timestamp, package transform version, and generic source-trail entities. It is portability traceability only, not provider-authored provenance, source correctness, identity proofing, clinical validation, clinician review, legal attestation, diagnosis, prescribing, monitoring, coverage, or care recommendations. Tracker FHIR rows use generic category labels and package-local ids, not raw tracker event ids, source tables, source platforms, private notes, or free-text labels. The separate clinical-history.json artifact is the review and provenance companion for clinical-history rows, including accepted appointment, family-history, related-person contact, source-device, and specimen lab-provenance context that can also appear asAppointment, FamilyMemberHistory, RelatedPerson, Device, and Specimen in the bundle, not a second vaccine, allergy, medication-fulfillment, adherence, genetic-risk, screening, or patient-condition decision layer, and not appointment scheduling, provider messaging, caregiver authority, emergency sharing, device pairing, live sync, monitoring, alerts, hardware control, medical-device validation, recall or warranty advice, sample adequacy, lab validation, retest advice, collection instruction, or care guidance.

Source identity attribution in the package is aggregate-only. It counts catalog coverage, file-ready source identities, connected provider-network sources, import metadata, row-level source identities, source categories, and generic source gaps without including provider names, filenames, hashes, storage paths, raw subject identifiers, or connection identifiers.

The record-network ledger summarizes provider-record connection status, sync freshness, aggregator category, ingest-event status, payload type, staged row counts, and next review actions. It uses package-local references instead of provider identifiers, aggregator user IDs, external event IDs, raw error messages, file URLs, identity documents, or raw FHIR payloads. It is export provenance only, not live network access, identity proofing, record sharing, auto-merge, clinical validation, diagnosis, prescribing, lab ordering, coverage review, or legal advice.

The wearable lifecycle ledger summarizes Apple Health, Health Connect, wearable export, and aggregator connection status, sync freshness, ingest-event status, payload type, staged row counts, and next review actions. It uses package-local references instead of connection IDs, external event IDs, raw error messages, file URLs, device identifiers, credentials, tokens, or raw wearable values. It is export provenance only, not live sync activation, device control, source-accuracy proof, real-time monitoring, alerts, diagnosis, prescribing, care decisions, or legal advice.

Ojava Coach and source-acquisition planning can also use the same lifecycle evidence to prioritize repair before new source acquisition. Reauthorization, revoked access, failed ingest, and stale or never-synced provider-record sources are summarized as generic repair actions, without exposing provider names, raw event ids, URLs, tokens, or raw error messages.

The package also includes a purpose-specific consent receipt ledger. It records active, revoked, denied, malformed, and missing clinical-context consent receipts, plus whether bounded import, source-file, or hash evidence was present in the consent scope. Direct file names, paths, URLs, contact details, tokens, and raw scope values are redacted from the ledger. Consent receipts are provenance for your review, not a new authorization, share link, provider disclosure, or legal approval.

The package also includes a clinical-history portability artifact for accepted FHIR and record-import history rows. It organizes encounters, appointments, conditions, procedure history, service-request metadata, immunization history, medication dispense or administration history, care plans, goals, related-person contact context, bounded source-device context, and DocumentReference metadata with package-local row references, generic source-trail labels, dates, coding coverage, missing inputs, and review questions. It does not include raw import ids, filenames, attachment URLs, attachment hashes, provider identifiers, or embedded attachment content. It is review and portability context only, not a signed medical record, clinician-review proof, attachment interpretation, order or referral completion, diagnosis, prescribing, medication fulfillment proof, administered-care proof, adherence proof, vaccine decision, caregiver authority proof, emergency contact sharing, device pairing, live sync, monitoring, alerts, hardware control, medical-device validation, recall or warranty advice, coverage review, or care recommendation.

Use the health data package before a deletion or correction request when possible. Ojava Coach and Settings can prepare a selected-data rights request with the data category, source, and date range, while keeping account deletion, source-app deletion, backup purge promises, and legal deadlines out of the local request draft.

The package is built to be reproducible. When Ojava has the original source-file hash, the manifest keeps that SHA-256 value, links the package back to the import, file, job, row, and package-local audit references that produced it, and gives each generated artifact its own SHA-256 digest. The export audit artifact is a sanitized ledger: it keeps event chronology, linked object class, source-window status, retained or dropped metadata keys, and artifact digest references by name, while leaving out raw audit ids, raw object ids, table names, arbitrary metadata values, and your record contents.

The package also includes data-dictionary.json. That artifact catalogs each package file, its package key, grain, sensitivity class, source inputs, transform versions, lineage pointers, intended consumers, privacy controls, limitations, and whether the artifact is covered by the package digest map. It is metadata for portability and provenance review only. It does not contain record contents, validate clinical meaning, prove source correctness, create a data-use agreement, or activate sharing.

The manifest also includes an audit-continuity check. It tells you whether the recent audit window looked bounded or truncated, whether included events had usable timestamps, whether those events were linked to package objects, whether package lineage covered the expected import and tracker rows, and whether generated artifact digests were finalized. This helps review the provenance story behind an export. It is not legal retention proof, clinical validation, record sharing, deletion, coverage review, or legal advice.

The manifest also carries source contract receipt coverage. User-import receipts summarize source type, access tier, fields, row counts, hash presence, evidence level, and limitations. Export artifact receipts can include generated artifact hashes so you can review package integrity without turning the package into clinical validation or a coverage decision.

The source-quality artifact also includes source-feed contract baselines. Those baselines show whether each source feed has accepted rows, pending review, parser loss, failed files or jobs, hash evidence, lineage coverage, and freshness gaps. They are export-review metadata, not live monitoring or a claim that the source is clinically correct.

The source-quality artifact also includes source identity consistency. It reports aggregate source-trail, subject-signature, dependent-context, generic-source, agreement-review, and reconciliation counts before exported data is summarized across sources. It is provenance review only, not identity proofing, record merging, source correctness, research anonymization, diagnosis, prescribing, lab ordering, or coverage review.

The source-quality artifact also includes unit-normalization readiness for numeric rows. It records recognized unit labels, missing unit rows, unrecognized unit text, and mixed-unit groups so a reviewer can see which source rows need cleanup before reuse. It does not convert units, validate a result, or decide source correctness.

It also includes a source-priority policy when accepted source trails or reconciliation conflicts are available. That policy gives a human review order for source trails and conflict groups. It does not choose a winning result, validate clinical correctness, hide conflicting data, or change your records.

The source-quality artifact also includes records-search and visit-prep coverage. It counts accepted and in-review searchable rows, source trails, searchable categories, doctor-note coverage, imaging-report coverage, report/document coverage, and missing context labels so a reviewer can see what the package can support before a visit. It does not interpret images, send records, message providers, decide coverage, or recommend care.

Source-cohort transparency counts which rows were candidates for the package, which accepted dated rows were included, which rows were excluded, the exclusion reasons, generic candidate source mix, date window, and standard-coding coverage. It helps explain the denominator behind the exported source-quality artifact without exposing filenames, source resource ids, raw values, or free-text notes.

The source-quality artifact also carries a replayable source cohort definition manifest. It records the package scope, stable manifest id, inclusion rules, exclusion reasons, source-trail counts, date window, coding coverage, privacy protections, and disabled research or clinical claims. The manifest is designed for provenance review only. It does not turn the package into a research cohort, real-world-evidence dataset, clinical-validation result, or regulatory anonymization artifact.

Package replay compares the current export against a saved prior source-quality snapshot when one exists. First exports, or exports without a saved source-quality snapshot, show the replay audit as not replayable instead of claiming that a cohort was reproduced. The prior baseline in the package is counts-only and minimized, not raw record data.

The package also includes a source-cohort-scoped de-identified snapshot. Ojava applies the package-wide source cohort rules first, so only accepted, dated, current rows enter that snapshot; pending, stale, future-dated, or undated rows are counted as exclusions before tokenization. The artifact carries the replayable cohort manifest id, included-row counts, source-neutral snapshot-local tokens, and the same privacy boundary as the broader de-identified snapshot. The coarse source kind can still say import, file, or job, but the token string itself does not reveal that class.

The source-quality artifact also includes a source-normalization release packet. It records the workflow-manifest status, release fingerprint, release domains, rollback review plan, and disabled claims for the package baseline. This is change-control evidence for human review, not a claim that clinical normalization is certified, source correctness is decided, or conflicting values have been automatically resolved.

Settings can also download a de-identified review snapshot from the same package inputs. That snapshot removes direct identity, filenames, raw row and audit ids, raw values, free-text notes, and exact timestamps; it keeps only source-neutral snapshot-local tokens, month-level date buckets, source-quality signals, and counts. Sensitive categories and sensitive-only source metadata are withheld by default. This is useful for internal review or data-room style analysis when you need the shape and provenance of the record set without handing over the full patient-facing package.

The de-identified snapshot now carries a privacy-risk review profile. It checks the already-tokenized snapshot for thin source patterns, single-event domains, small month and source-month cells, sensitive-category withholding, and truncated source windows before you share it for review. The profile names review readiness and small-cell findings only. It does not expose raw values, filenames, exact timestamps, or free-text notes.

CSV spreadsheet export

Prefer a spreadsheet? From Settings, under Data portability, you can export your accepted results, your medications, and your wearable metrics as CSV files to open in Excel, Google Sheets, or Numbers, handy for charting a marker over time or keeping your own copy. CSV uses the same sensitive-category protection as the FHIR export.

Fitness tracker exports

From Fitness, the tracker export card can download a multi-file ZIP with separate nutrition, exercise, progress, hydration, meal-plan, saved nutrition-library, and full-tracker CSV files. You can also download one full tracker CSV or smaller CSVs for food, exercise, hydration and fasting, or body measurements and meal plans. Each tracker export supports a start date, an end date, or all time. When email delivery is active, you can also send the same ZIP to your signed-in account email. Ojava does not send tracker exports to arbitrary recipients from this action, and if email is not active the download path still works.

The saved nutrition-library CSV carries account-backed custom foods, saved meals, saved-meal items, recipes, recipe ingredients, favorite shortcuts, shopping-list lines, and nutrition goal-setting summaries when those settings exist. It is separate from logged intake so reusable templates stay portable without being counted as food you ate. Incomplete saved-meal or ingredient macros are labeled incomplete instead of being summed as zero.

The Food Log nutrition report is a smaller, visit-prep-friendly export. It starts with the last 7 days, but you can choose a custom reviewed period up to one year, then copy share text, export TXT, print, create an expiring private snapshot link, or download CSV for that same selected range. The report includes daily totals, entry detail, label nutrients, source counts, and a prior same-length comparison when available.

Sensitive-category protection

Ojava recognizes five categories of records as sensitive and protects them by default:

• Mental & behavioral health: psychiatry, therapy, depression, anxiety, antidepressants.
• Substance-use treatment: addiction care, detoxification, medication-assisted treatment.
• Reproductive & sexual health: pregnancy, contraception, STI tests, fertility.
• Genetic: genetic tests, carrier screens, family-history risk panels.
• HIV-related: HIV status, CD4 counts, antiretroviral medications.

This mirrors the heightened care these categories deserve: you choose what to share, and what you do not share stays private in your account. See Privacy & your data for how the same protection applies to what Ojava Coach can see.