Privacy Policy

Last updated: May 24, 2026

BiomAPI is an interoperability and data transport service for optical biometry data. It extracts, validates, normalizes, exports, and temporarily shares structured biometry data so users can move data between systems more easily.

BiomAPI is not a medical device. It does not diagnose, recommend treatment, calculate clinical decisions, or replace professional review. It does not intentionally alter clinical measurements; manual edits are user-directed, and automated processing is limited to extraction, validation, normalization, formatting, and transport.

LLM-based processing is not error free. BiomAI may misread a report, omit data, assign values to the wrong eye, misunderstand device-specific formatting, or produce otherwise incorrect structured output. Other processing modes are designed to be deterministic, but may still produce incorrect or unexpected results because of invalid input, user entry errors, schema constraints, software defects, or integration issues. In all scenarios, and especially when automated extraction is used, the user is responsible for independently reviewing and confirming the data before relying on it.

User Responsibility

You are responsible for ensuring that you have the individual, institutional, contractual, and legal rights needed to upload and process any report or data submitted to BiomAPI. This includes obtaining any required consent, authorization, institutional approval, or other lawful basis; complying with local health-data and privacy rules; and anonymizing or redacting printouts before upload when required.

BiomAPI helps minimize stored identifiers, but it does not make an upload lawful by itself.

What BiomAPI Processes

BiomAPI handles two input types:

Input	Processing path
PDF or image	BiomAI extracts structured data using Gemini
JSON	BiomJSON validates and normalizes the submitted structure

JSON inputs may be previously stored BiomAI results, user-edited results, manually entered data from the web app, device integrations, EHR exports, or other directly formed payloads. BiomDIRECT is not a separate processing engine; it is the provenance label used when the submitted or edited data was directly formed rather than extracted by BiomAI. BiomDIRECT data is still validated through BiomJSON.

Responses can include biometer details, patient demographics, eye measurements, optional notes, optional posterior keratometry, metadata, and optional BiomPIN information.

In ordinary processing responses and browser-local context, patient names are forcibly converted to all-caps initials/acronyms by the schema validator. For example, John Douglas Doe becomes JDD. This acronym and the patient ID are not stored in the BiomPIN database: before a BiomPIN payload is encrypted and stored, BiomAPI removes both patient name/initials and patient ID.

BiomAPI does not store raw uploaded files after processing. During live processing, the service necessarily sees submitted content in plaintext so it can validate files, call Gemini when BiomAI is used, build the response, and optionally create an encrypted BiomPIN record.

BiomAI and Gemini

When BiomAI is used, the uploaded PDF or image is sent to Google Gemini with an extraction prompt so that it can return structured biometry data.

Server-managed BiomAI uses Google Cloud managed Gemini models through the Gemini Enterprise / Gemini Enterprise Agent Platform family of services. Google Cloud states in its Service Specific Terms and Cloud Data Processing Addendum that customer data is not used to train or fine-tune Google AI/ML models without the customer’s prior permission or instruction.

BiomAI follows Google Cloud’s documented zero data retention requirements by not using Gemini features that require additional prompt or output retention, such as Grounding with Google Search, Grounding with Google Maps, or Gemini Live session resumption. The remaining exception is Google abuse-monitoring prompt logging that applies to the deployment. Google also describes Gemini in-memory caching as not-at-rest storage, project-isolated, used only for performance, and subject to a 24-hour TTL.

If you provide your own Gemini API key, BiomAPI uses that key for the extraction request. That BYOK processing path is governed by your own Google account, project, billing status, region, and data-processing terms, and responsibility for that part of the processing pipeline falls on you.

BiomPIN and Browser Storage

BiomPIN is optional through the API, but is turned on by default in most integrations. When requested, BiomAPI creates a temporary encrypted copy of the standardized response for later retrieval with a code such as lunar-rocket-731904.

BiomPIN uses a two-part design: lunar-rocket is the stored share ID, and 731904 is the numeric PIN, which is never stored. The encryption key is derived from the numeric PIN using Argon2id, and the payload is encrypted with AES-256-GCM. Without the full PIN, including the numeric suffix, the stored payload cannot be decrypted.

Before a BiomPIN payload is encrypted and stored, BiomAPI removes patient name/initials and patient ID. A BiomPIN retrieved from another browser or device therefore returns the biometry data without those two identifiers.

The web app may restore patient context locally for convenience. Browser localStorage may contain BiomPIN history, patient initials/acronym, patient ID, BiomPIN expiry time, saved BiomAPI API key, saved Gemini BYOK key, and UI state. This data remains on that device/browser until cleared by the user, the browser, or app cleanup logic. Integrations may pass patient context in a URL fragment such as #biomctx=...; URL fragments are not sent to the server in normal HTTP requests. Patient identifiers should not be placed in query parameters.

BiomPIN records expire automatically after the configured expiry period, 744 hours or 31 days by default. Expired records are pruned when new BiomPIN records are stored. A BiomPIN record is also permanently deleted after the configured number of failed PIN attempts, 3 by default.

Logs and Analytics

BiomAPI processes operational information needed to run the service, protect the API, troubleshoot issues, and enforce quotas. This includes IP address, request path and method, request ID, timestamp, authenticated user ID when an API key is used, engine type, file extension, rate-limit usage, error category, device model/name, BiomAI processing time, and BiomAI token usage metadata.

Operational logs do not store raw uploaded files, response payloads, clinical measurements, patient demographics, patient names, patient IDs, notes, or model output.

BiomAPI analytics, when enabled for a deployment, are limited to product and reliability events such as processing attempts, retrieval attempts, status checks, usage checks, CSV/export actions, engine type, authentication type, file extension, request ID, error type and stage, BYOK state, BiomPIN-requested state, response count for CSV/export actions, device model/name, processing time, and BiomAI token counts. Analytics events do not include raw uploaded files, response payloads, clinical measurements, patient demographics, patient names, patient IDs, notes, or model output.

Security and Deletion

BiomAPI uses HTTPS encryption in transit. BiomPIN records are encrypted at rest using a zero-knowledge design: the numeric PIN needed to derive the encryption key is not stored on the server, and patient name/initials plus patient ID are excluded from the stored encrypted payload.

This zero-knowledge model applies to stored BiomPIN records. It does not mean the service cannot see data during active processing, but that plaintext processing context is discarded immediately after processing is complete.

BiomPIN records are temporary and expire automatically. They can also be destroyed by failed PIN attempts. Browser-local history and saved keys can be cleared from the web app or by clearing the browser’s site data.

Contact

For privacy, security, or compliance questions, contact the BiomAPI developer using the contact form on the website.