Organizing & searching records

Drop any file and Ojava sorts it

The import flow works the same way every time: drop any health file, Ojava detects what it is, extracts the results into a review queue, and you accept the ones you want. Your records are never auto-added; they stay in review until you confirm them.

Automatic type detection

When you drop a file, Ojava checks the filename and peeks at the content to figure out what you've uploaded:

• Lab results CSV: a spreadsheet with column headers like "reference range," "units," or test names.
• FHIR health-data bundle: structured clinical data as JSON, XML, or Bulk FHIR NDJSON (what modern health apps and the nationwide record networks use), including visit, appointment, medication-reference, specimen, contact/caregiver, care-directory, source-device, and source-lineage context for review.
• C-CDA clinical summary: your health summary exported from a hospital or clinic portal, the standard US clinical document format.
• HL7 v2 lab message: an ORU result message (a .hl7 file, or one that starts with an MSH header) exported from a lab or hospital interface, the older pipe-delimited standard many labs still send.
• Apple Health export: your data from Apple Health, including wearable readings, vitals, symptoms, and medications.
• Wearable CSV: export files from Oura, Whoop, Fitbit, Garmin, or other fitness trackers.
• Medication list: a CSV, text file, or selectable-text PDF listing your current and past medications.
• Insurance and billing documents: insurance cards, explanation-of-benefits files, medical bills, prior-authorization letters, and structured payer FHIR claim or coverage resources.
• Genomics and microbiome reports: raw genotype files, genetic-testing reports, gut microbiome reports, and stool-analysis exports stay labeled for sensitive review instead of being treated as ordinary scans.
• PDFs, images, and documents: selectable lab and medication-list PDFs use deterministic extraction; JPG or PNG photos and up to three pages of common scanned PDFs use the local document-image path; clinic notes, imaging reports, unreadable pages, and unsupported documents stay stored for manual review when Ojava cannot read them safely.

Detection is a two-step process: first, the filename tells Ojava what to expect (a .pdf is usually a scan; a .csv might be labs or wearable data); then, the first ~4KB of the file refines the guess by looking at its actual structure. If Ojava is unsure, it asks you to pick the type yourself, so nothing is misinterpreted.

Auto-parsed formats

For the formats Ojava knows how to read, extracted results show up immediately in your review queue:

• Lab CSV: rows are parsed into individual test results with dates, values, units, and reference ranges (if present).
• Selectable lab and medication PDFs: embedded PDF text is read on the server, then only recognizable lab-result or medication-list lines are queued for review.
• FHIR JSON, XML, and NDJSON exports: observations, vital signs, medications, medication dispense or administration history, immunizations, problems, allergies, encounters, appointments, procedure history, service requests, care plans, goals, family history, questionnaire responses, specimen context, related-person contact/caregiver context, bounded Device source context, bounded Provenance source-lineage context, document references, practitioners, organizations, care teams, and payer claim or coverage resources are extracted into the same review queue format as everything else. Companion FHIR Medication resources can resolve medication names and codes for referenced medication rows, but they are support resources rather than extracted review rows. Bulk FHIR NDJSON is read one FHIR resource per line.
• HL7 v2 ORU messages: the OBX result segments are parsed into individual lab-result rows with values, units, and reference ranges, queued for review like every other lab source.
• Apple Health exports: metrics like heart rate, sleep, steps, workouts, body measurements, and symptom records are parsed out.
• Wearable CSV files: readiness, sleep scores, HRV, resting heart rate, training load, recovery, and other wearable metrics are recognized and normalized.

The same review queue is the destination for provider-record retrieval. Ojava now has an inert Persona plus Metriport implementation: Persona starts a hosted identity inquiry, Metriport completes its own identity and authentication steps, and signed record-ready webhooks route retrieved FHIR into pending review. The reviewed identity migration is live; retrieval now waits on provider accounts, server credentials, webhook configuration, and full live verification.

C-CDA and complex clinical documents

When you upload a C-CDA or other clinical XML from your hospital portal, Ojava scans the document for lab results, vital signs, medications, problems, procedure history, immunization history, and allergy or adverse-reaction entries. It keeps source codes such as LOINC, SNOMED CT, CVX, or RxNorm when the file provides them, extracts what it can reliably read, and skips anything unclear, so only the things you can verify show up for review. This means you get the useful data without the risk of a misread value snapping into your record.

FHIR and C-CDA imports can also queue reviewed clinical history: visits, appointments, procedure history, service requests, allergy or intolerance history, immunization history, family-history resources, questionnaire responses, related-person contact/caregiver context, specimen context, care plans, goals, and document references. Encounter history helps reconstruct what happened and what to ask next. Procedure history and service requests are stored as visit-history context with clear labels. Medication dispense and administration resources are stored as medication-history context, not prescribing, pharmacy fulfillment, administered-care proof, adherence proof, or clinician review. Companion FHIR Medication resources can enrich referenced medication rows with names and source coding, but they stay support and traceability data only. Questionnaire responses are stored as document-style input context for review and clinician-prep checklists, not score interpretation, diagnosis, crisis assessment, therapy, sleep-study decisions, or treatment advice. Related-person rows are stored as document-style contact/caregiver context only. When a reviewed source explicitly labels one as an emergency contact, Ojava can reuse the bounded name, relationship, and contact-method count in local emergency-card prep, but not the raw contact value and not as emergency sharing, consent proof, messaging, provider access, clinical relationship validation, caregiver invitation, or care guidance. Specimen rows are stored as document-style lab provenance context and can export as metadata-only local FHIR Specimen resources after acceptance, not sample adequacy, lab validation, diagnosis, retest advice, collection instruction, or care guidance. Family history resources are stored as document-style family-history context for review and visit prep, not as conditions you have. FHIR practitioners, organizations, and care teams are stored as document-style directory context for review only, not a provider directory, inbox, booking rail, referral route, or clinician access. Allergy rows keep medication-safety context, not allergy diagnosis or severity verification. Immunization rows keep vaccine-history context, not vaccine decisions. Care plans and goals are stored as document-style prep context. Document references are source context or attachment pointers, not proof that a clinician reviewed the content. After you accept a FHIR document reference, Coach can organize its title, type, category, date, source trail, and attachment pointer metadata into a local review checklist. It still does not read the attachment, interpret an image or scan, send the record, decide coverage, or prove clinician review. Accepted after-visit summaries and discharge instructions can also feed a post-visit readiness packet: Coach can name the source-backed follow-up tasks, medication-change mentions, pending tests or referrals, warning-language excerpts, and missing source details to review before a follow-up. It does not change clinician instructions, triage symptoms, order labs, route referrals, send messages, or contact a clinician. Settings exports can also package accepted clinical-history rows into a portability artifact with package-local row references, source-trail labels, coding coverage, document metadata, questionnaire-response input context, imaging-study metadata, allergy, immunization-history, medication dispense or administration history rows, and review questions. Accepted imported FHIR or C-CDA allergy and immunization rows can also enter the package FHIR Bundle as AllergyIntolerance andImmunization resources, while accepted encounter, condition, procedure, service-request, medication-dispense, medication-administration, care-plan, goal, family-member-history, related-person, questionnaire-response, imaging-study, source-device, specimen, and document-reference rows can export as local FHIR history resources. Package tracker events can also enter the package FHIR Bundle as genericObservation resources for scalar food, workout, wearable, symptom, and mood metrics, with package-local ids and without raw event ids, source tables, source platforms, private notes, or free-text labels. DocumentReference exports carry metadata only, not attachment URLs, embedded files, raw source ids, or attachment interpretation. QuestionnaireResponse exports carry item labels but not answer values or scores. ImagingStudy exports carry bounded study metadata but not endpoint URLs, image bytes, report text, findings, impressions, or interpretation. These uses are portability, medication-safety, vaccine-history, and visit-history context only, without attachment interpretation, allergy diagnosis, severity verification, vaccine decisions, family diagnosis validation, genetic-risk scoring, screening decisions, genetic-test decisions, completed orders or referrals, clinician-review proof, or care recommendations. Imported FHIR Provenance resources are stored as bounded source-lineage context with target counts, capped safe references, activity, agent labels, entity roles, policy counts, and signature counts only. They do not store signature payloads, credential-bearing URLs, raw entity payloads, or full policy URLs, and they do not prove authenticity, legal attestation, consent, chain of custody, source correctness, clinician review, clinical validation, or authorization. Accepted specimen and provenance metadata can be summarized for local Coach review as source-lineage context, but not as lab validation, sample adequacy, consent proof, chain-of-custody proof, or a care action. Imported FHIR Device resources are stored as bounded source-device context with labels, manufacturer, model, version, owner or location labels, manufacture dates, and counts for serial, UDI, or identifier presence only. They do not store raw serial numbers, UDI values, or device identifiers, and they do not pair a device, activate live sync, monitor, alert, control hardware, validate a medical device, advise on recalls or warranties, prove source correctness, prove clinician review, diagnose, or recommend care. Accepted Device rows can also export as metadata-only local FHIR Device resources with package-local ids and the same bounded metadata only. Package-local FHIR Provenance resources may also appear in the exported FHIR bundle to trace Ojava package resources back to the package transform and generic source trails. Those package-local resources are export traceability only, not new clinical facts, provider-authored provenance, attachment interpretation, clinician-review proof, or care recommendations. Payer FHIR resources such as claims, coverage, eligibility, and insurance-plan records are stored as document-style review rows, not clinical measurements.

Everything stays in review until you accept it

Whether you drop a single lab PDF or import a whole health summary, every extracted result appears in your review queue with a status of “in review.” Ojava does not assume anything is correct or add anything to your live record without your say-so. You can:

• Accept results you recognize and want to keep.
• Reject results that are wrong, outdated, or not relevant to you.
• Leave results sitting if you want to think about them.

Once you accept a result, it joins your searchable record. Rejected results are kept for your reference but do not become part of your clinical context or show up in Ojava Coach's understanding of you. Nothing is final until you confirm it.

Ojava Coach can also receive a deterministic import-review decision packet for pending rows. It names whether each row has a readable date, usable value or source text, unit context, source trail, and standard coding before you accept or reject it. The packet helps organize review questions only: it does not auto-accept rows, auto-reject rows, certify source accuracy, validate clinical meaning, diagnose, order labs, or complete care actions.

Source quality

The review workspace also shows a source-quality summary for the rows in scope. It checks practical record-readiness details: how many rows are accepted, whether dates are present and readable, whether values and units are usable, how many source files are represented, which record types are covered, which rows carry FHIR or provider-ingest lineage, and which clinical rows include standard coding such as LOINC or RxNorm. The score helps you see what to tighten before using the record in Coach or Reports.

Each parsed upload also gets a source-feed datasheet. It shows what Ojava detected, how many rows were normalized, how many resources, rows, or NDJSON lines were skipped because they were malformed, incomplete, or unsupported, whether the file is stored for manual review, and the next repair step. This makes parser loss visible instead of hiding it behind a successful upload message.

Source contract receipts sit beside that datasheet. They summarize the source type, access tier, fields and units when available, row counts, hash presence, evidence level, and limitations for each import. Ojava Coach sees only the aggregate receipt status, never raw filenames or hashes.

The same review workspace also shows network readiness for provider-record sources. It separates Ojava's visible source catalog, the 150,000+ provider-source architecture target, approved record-network options, target provenance, missing activation gates, and any record-network lifecycle repair work before live provider-record pull is treated as available. The target is a planning benchmark for the aggregator architecture, not a claim that Ojava has live access to every provider source today.

The companion activation diagnostics packet breaks that same setup into ready-versus-gated rails: connector selection, webhook ingest, identity proofing, bounded verified demographics, review-queue reuse, and lifecycle repair. It does not prove identity, activate provider access, validate source correctness, auto-merge records, diagnose, treat, monitor, decide coverage, or provide legal advice.

Ojava also runs a source plausibility review on imported observations. It looks for coarse source-shape issues like future dates, unreadable dates, non-finite numeric values, gross value shapes, unit mismatches, and rows that cannot be checked with a conservative rule. These flags are review prompts only. They do not prove a value is clinically wrong, validate a source, recommend retesting, order labs, or guide care.

The same plausibility review now covers common lab-panel source shapes, including lipids, TSH, liver enzymes, creatinine, hemoglobin, platelets, sodium, and potassium. The ranges are intentionally broad import sanity checks for source review, not reference ranges, abnormal flags, diagnoses, or retesting advice.

Source-feed contract baselines add an operations view on top of those receipts. For each source, Ojava checks whether the feed has accepted rows, pending review work, parser failures or skipped rows, source-file hash evidence, lineage coverage, and a reasonable freshness window for that kind of source. This helps you see whether a source trail is ready for review or needs repair before it appears in a report or Coach answer.

The same source-quality packet now includes records-search coverage. It counts accepted and in-review rows by searchable category, source-trail breadth, and whether imaging reports, doctor notes, and other report documents are present. Missing context is labeled plainly, such as doctor notes or imaging reports missing from your record, so Coach and Reports can prepare a visit without deciding whether a source is correct, interpreting images, sending records, messaging providers, sharing in emergencies, or deciding coverage.

The packet also includes source-cohort transparency. For a Coach question or a package export, Ojava counts the candidate rows, which accepted dated rows were included, which rows were excluded, why they were excluded, the date window, included and candidate source-trail counts, and how many included rows carry standard coding. Package and export packets can also show a generic candidate source mix. This is a practical denominator for trust-checking an answer. It is not research evidence, clinical validation, source correctness, diagnosis, or care guidance.

Ojava also builds a replayable source cohort definition manifest from the same denominator. The manifest records the scope, stable manifest id, inclusion rules, exclusion reasons, date window, source-trail counts, coding coverage, privacy protections, and disabled claims. It helps you see how the cohort could be reconstructed later without exposing row ids, filenames, source names, raw values, or free text. It is a provenance specification only, not a research cohort or real-world-evidence claim.

When a manifest is available, Ojava can run a source cohort replay audit against the current reviewed rows. The audit compares the saved manifest with a fresh deterministic rebuild and reports only aggregate differences such as row counts, source-trail counts, date window, coding coverage, exclusion reasons, and workbook summary. It does not expose raw identifiers and is not a tamper-proof legal attestation, source correctness certificate, research-cohort claim, or care recommendation.

Settings package replay uses this same audit, but only against a real saved prior source-quality snapshot. If no prior snapshot exists, the package says the replay is not replayable instead of synthesizing a baseline from the export being generated.

For a source-quality question, Ojava can also build a question evidence workbook. The workbook gives Coach a stable review id, the requested record areas, candidate and included row counts, generic evidence-row labels, generic source-trail labels, excluded-row reasons, date window, and coding coverage. It is designed to answer "what supports this answer?" without exposing filenames, import ids, source-file ids, storage paths, raw source names, or source resource ids. It is a personal review aid only, not a research cohort, source-certification result, diagnosis, coverage decision, or care decision.

Source identity consistency is another review layer in the same packet. It checks accepted source-trail breadth, aggregate subject-signature groups, dependent-context hints, generic source metadata, same-day agreement review, and reconciliation findings before a packet summarizes across sources. It gives you counts and repair steps only. It does not prove identity, merge people, decide which source is correct, anonymize records for research, diagnose, prescribe, order labs, decide coverage, or guide care.

Source setup readiness is a separate companion to source quality. It answers the practical question of how a wearable, app, health hub, or CSV export can enter Ojava: imported rows already present, file import ready, native health-hub path gated, cloud or partner path gated, or unsupported and requestable. That status does not validate the medical meaning of a record and does not turn on live partner sync, external account actions, writeback, device control, monitoring, or alerts.

Source-acquisition planning combines the source-quality summary, whole-health coverage gaps, and the approved provider catalog to rank what to add next. It can point you toward repairing current imports, uploading an existing lab or imaging report, exporting from a wearable or nutrition app, or waiting on an owner-gated records connector. It does not order tests, choose providers, pull records without consent, or decide what care you need.

Once the review workspace has source data, you can save a minimized source-quality snapshot. Later snapshots compare against that real saved baseline to show parser loss, review backlog changes, source failures, freshness regressions, and source or record-type mix changes. The snapshot history is for source reliability only and omits raw values, free text, filenames, source-file ids, import ids, hashes, storage paths, and original raw payloads.

The same source-quality area now shows record-repair prompts when common lab or vital categories are older or not on file. Each prompt stays neutral: add an existing record if you have one, or bring the question to a clinician. Ojava does not decide that a lab is needed or that care is due.

Ingestion turns those same checks into a source-governance packet before a record leaves intake. It adds a population-style datasheet over source coverage, completeness, timeliness, cleanliness, and lineage so you can see whether the packet is broad enough to review. It describes record provenance only, not a research cohort or a medical validation.

The intake workspace also adds a field-level profile by source and record type. It checks whether each group has dates, values, units, standard codes, and lineage, then points to the weakest field to review first.

Source unit normalization readiness sits beside that field profile. It recognizes common unit labels and aliases for numeric rows, then flags missing units, unrecognized unit text, and same-marker groups that mix recognized units. It does not convert values, validate clinical meaning, set targets, or interpret whether a result is normal.

Ingestion and Reports build a canonical event ledger and semantic normalization profile from the same rows. The event ledger keeps each reviewed item tied to its source, event domain, date, value, unit, code system, review state, and normalization gaps. The semantic profile summarizes which code families are present and which clinical concepts are still source-named instead of standard-coded. This helps you understand how traceable the record is before it feeds Coach or a report packet.

The packet also builds a longitudinal source profile from that event ledger. It looks at dated event windows, repeated concepts, source-trail continuity, and domains that are thin over time. That helps you see whether a packet has a useful source trail, without claiming the record is a research cohort or a clinically validated trend.

When the same accepted, dated concept appears from more than one source trail on the same day, Ojava also builds a source-agreement checkpoint. It can show when sources line up, or when values, units, text, or mixed numeric and text shapes should be checked against the original records before Coach or Reports leans on them.

That same cross-source review feeds the source identity consistency packet. If Ojava sees mixed subject-signature groups, dependent context, generic source metadata, or source conflicts, the packet stays in review and names the cleanup step instead of quietly blending those rows together.

For broad lab imports, Ojava also builds a lab draw reconciliation packet. It groups accepted lab rows by draw date and source trail, then names duplicate same-draw marker rows, unit conflicts, missing draw dates, and rows that are no longer tied to a source file or import. This helps you clean up a large panel before a visit. It does not validate the lab, decide whether a result is correct, merge conflicting units, order a retest, or interpret the result for you.

Ojava also ranks accepted source trails for review priority when conflicts exist. Provider or structured source trails with dates, values, units, lineage, and standard coding can be placed ahead of thinner manual context so you know what to inspect first. That ranking is only a review order; it does not choose the clinically correct source, hide conflicting rows, or edit your record.

Before you copy or export the source-quality packet, Ojava also builds a source-normalization release note. It groups parser accounting, canonical normalization, source reconciliation, drift and repair, and package export readiness into release domains, then shows a deterministic release id, fingerprint, review status, rollback plan, and disabled claims. This is change-control evidence for review, not proof that the clinical meaning is certified or that conflicting sources were automatically resolved.

Once there is source data, you can copy or export the source-quality packet from Ingestion or Reports. Empty intake state stays locked to a start-here message instead of offering a packet that would look ready without evidence.

Source quality is not a medical validation. It does not decide whether a result is clinically correct, diagnose anything, or tell you what care you need. It simply shows whether the imported data is more transparent to review.

Search your own data

Ojava indexes every observation you accept for full-text and fuzzy search. Ask things like "when was my last lipid panel?" and jump straight to the result, no scrolling through PDFs.

A health-memory timeline

The timeline shows what categories of data you've covered and what's missing, so you can see your record taking shape and spot the gaps worth filling before your next visit.

The same timeline can prepare a portable emergency card: accepted identity, allergies, medications, supplements, conditions, emergency contacts when present in your source rows, and recent context can be gathered into local card text for you to review, copy, or export. It uses the records you already accepted, not a separate emergency profile, and it stays under your control. Ojava also checks whether that short local card is ready to print or export by looking for required allergies, medications, and emergency contacts plus recommended condition and latest context sections. It does not create a QR code, live sharing link, provider inbox, permission workflow, emergency workflow, or care decision.

Symptom journal & medication list

Two patient-owned surfaces keep your context in one place:

• Symptom journal: log what you're experiencing over time, so patterns are visible rather than half-remembered.
• Medication list: track current and past medications, doses, schedules, refill context, reminder readiness, accepted imported medication-list reconciliation, medication supply and refill-readiness context from recent routine notes, self-reported taken/skipped history, and GLP-1 support notes for clinician prep when a current GLP-1 medication is on your list.

Insurance, bills, and benefits paperwork

You can upload insurance cards, explanation-of-benefits documents, provider bills, prior-authorization letters, and structured payer FHIR resources alongside your medical records. Ojava labels them so they can support benefits questions, prior-authorization prep, referral packets, and visit planning without mixing them into lab trends or clinical measurements. Provider-record sync uses the same boundary when claims or coverage resources arrive from a connected source.

If you accept an explanation of benefits, claim response, medical bill, or patient statement, Ojava can organize a local reconciliation checklist for your own review. The checklist looks for matching service context, reference numbers, and amount-style fields to bring into a call. It is not a bill audit, payment calculation, coverage decision, claim filing, appeal filing, legal opinion, or payer send.

Accepted payer documents are also checked for call-prep identifiers such as plan or payer name, member ID, group number, plan phone or portal path, and claim, authorization, invoice, or account references. These details stay local and review-gated, and Ojava does not verify benefits or contact a payer.

Genomics and microbiome reports

Raw genotype files, genetic-testing reports, pharmacogenomic summaries, gut microbiome reports, and stool-analysis exports are detected as their own source types. Ojava keeps them in review with the sensitive-record boundary visible, so they can support a clinician or genetic-counseling conversation without being mixed into ordinary lab trends.

Gut-health test reports from membership-based nutrition apps can be organized when you provide the report or when a partner path is available. Purchase, kit activation, sample processing, and result unlock stay inside the testing provider's account.

The same rule applies to lab result access. Ojava can track whether a lab-like source exists, whether accepted or pending lab rows are available, and what to bring into a visit-prep question. The testing provider still owns kit activation, sample processing, account recovery, and result release.

Connect a provider

Beyond uploading files, you will soon be able to connect your healthcare provider and pull your own records directly, no forms or faxing required. This uses your legal right of access to your own records, so no license is required on our side. Pulled records arrive in the same review queue for you to accept, just like an upload. You can also verify your identity once and let Ojava search the nationwide health networks for your complete chart across all your providers. Before any Persona inquiry is created, the records card explains that Persona will request a government ID and selfie for preliminary identity verification, lists the bounded result Ojava retains, and requires an explicit checkbox. You can refuse and keep using file import. Ojava records that purpose-specific choice, and the server will not create or reopen a Persona inquiry without a current affirmative receipt. Ojava Coach uses the same server-side activation rails when it answers source-acquisition questions, so it can distinguish configured record-network readiness from missing setup without exposing aggregator keys, webhook secrets, service-role keys, identity-vendor keys, raw identity documents, or provider-search results.

Scanned documents and photos

If a lab or medication-list PDF contains selectable text, Ojava can read the embedded text and queue recognizable rows for your review. Lab PDFs need known marker names and explicit numeric values. Medication-list PDFs need a medication-list heading or repeated medication-like rows, then preserve dose or frequency detail as review text. Either way, extracted rows stay in review until you accept them.

Photos and common scanned PDFs

A photographed page, such as a lab printout or medication label, is read directly by Ojava's AI model. For a common image-only PDF, Ojava rasterizes up to the first three pages and sends those page images through the same extraction path. It reads only what is clearly legible and skips anything ambiguous, cut off, or unclear rather than guessing. Every value it finds lands as a pending row in your review queue, exactly like every other import source, so nothing counts toward your record until you accept it. If a page is unsupported, unreadable, too large, or not a clinical document, Ojava keeps the uploaded source for manual review instead of inventing rows or marking the import failed.

Ojava keeps unstructured extraction governance separate from medical interpretation: the review packet checks whether extracted observations include exact source phrases, context qualifiers such as current, negated, or historical, confidence labels, schema and model accounting, skipped rows, unparseable lines, and a bounded review-sample list for low-confidence, rejected, missing-source, missing-qualifier, or metadata-missing cases. Samples are short pointers, not full document text, so they help you review the source trail before accepting rows without exposing raw filenames, hashes, storage paths, or full source payloads.

If you ask Ojava Coach whether scanned PDF or photo reading is ready, it can answer from the same activation packet used by the extraction route, reporting the local document-image path's status separately from the optional higher-fidelity OCR vendor track (AWS Textract by default, with Google Document AI and Azure Document Intelligence modeled as future options). That packet names server-only credentials, the model extraction key, the fail-closed validator, route wiring, and the pending review queue, without ever naming secret values.

Your consent, your control

Every record stays private to your account. You control what gets imported, what gets accepted, and when you delete something. At any time, you can export your complete record as a downloadable file to take with you or share with another provider. Ojava processes your records to organize and explain them, never to train AI models or sell your data.

Identity proofing has its own consent receipt. Ojava keeps the receipt, verification status, bounded legal name, date of birth, sex, residential address, provider IDs, and event times in your account. Ojava does not store the government-ID image, selfie, Persona session token, one-time link, Social Security number, license number, or raw webhook. Settings can stage a scoped deletion request for Ojava-held identity-verification data. That request is not immediate deletion.