ML Runtime and Data Ownership Strategy¶
Current state¶
The deployed OCR Ops service is not running Gemini or any other model. A paid Gemini credential is now stored server-side and was validated with a model-list request that sent no prescription content. There is still no Google model SDK dependency or enabled extraction adapter. LockedExtractionEngine intentionally refuses every real-evidence request. The only permitted workflow today is the provenance-marked synthetic demo pipeline.
The service's configured persistence is a separate MySQL-compatible operations database. Its checked-in schema contains OCR operations jobs, reviewer decisions, governance records, idempotency keys, and migration history. It does not store evidence bytes. Core remains a separate PostgreSQL-backed clinical authority.
Database decision¶
Keep Core as the clinical system of record. Keep OCR Ops as a separate operational store. Do not merge their databases.
| Responsibility | Authoritative system | Data that belongs there |
|---|---|---|
| Patient, profile, prescription, evidence ownership, and clinical workflow | Nirog Core | Canonical clinical entities and Core-issued evidence/job identifiers |
| Evidence file bytes | Core-controlled object storage | Original document objects and access policy |
| OCR execution state, idempotency, model-run provenance, reviewer actions, and governance | OCR Ops database | Opaque Core identifiers, trace IDs, bounded review metadata, and model-operation audit state |
| Confirmed downstream receipt | Nirog Core | Identifier-only confirmed review receipt; no document text, candidate set, or diagnosis context |
This separation prevents the OCR service from becoming a second clinical authority. A future live adapter should receive a short-lived Core-authorized evidence reference, never a public URL or browser-uploaded file, and should persist only the minimum operational metadata needed for review and audit.
Gemini decision¶
Do not add a generic or free Gemini API key for real prescription evidence. Google states that its unpaid Gemini API services may use submitted inputs and outputs to improve products and may involve human review; it explicitly says not to submit sensitive, confidential, or personal information to unpaid services.1
For a synthetic-fixture-only prototype, a paid Gemini API project may be considered after a server-only key is supplied. Paid Gemini API services do not use prompts or responses to improve Google's products, but Google still states that prompts and responses can be logged for a limited period for safety/security purposes and may be transiently stored or cached in countries where Google or its agents maintain facilities.1 This is not a production PHI approval.
For any real prescription evidence, first obtain a documented compliance decision for the exact Google Cloud product, project, region, billing tier, data-processing terms, and any required BAA. Google describes HIPAA compliance as shared responsibility, requires customers to evaluate their own obligations, and advises using only products covered by the applicable BAA when handling PHI.2 This page is technical architecture guidance, not legal advice.
Gemini must be used only for bounded extraction, never diagnosis, medication changes, or autonomous clinical advice. Google’s Gemini API terms prohibit use in clinical practice or for medical advice and require the developer to determine appropriate safety and factuality controls.1 Gemini safety feedback should be captured as non-clinical operational telemetry; safety settings must not be weakened to force an extraction through.3
Live adapter input contract¶
The production-capable adapter will use Gemini structured output with a constrained JSON schema for medication strings, dose/frequency text, confidence, uncertainty, and non-diagnostic document context. Gemini's official structured-output guidance supports JSON Schema response formats and recommends schema validation in the client; OCR Ops will validate every response before deterministic matching or review-packet creation.4
Core will provide a per-job, time-limited evidence URL only after a successful worker lease. OCR Ops will pass that authorized evidence to Gemini in memory. For small, transient files this can use inline input; large or reused files require a different method. Gemini documents a 100 MB inline/external-URL limit, with PDF limited to 50 MB for inline data, and notes that temporary File API uploads are retained for 48 hours.5 OCR Ops will therefore enforce a smaller configurable limit, retain no evidence bytes itself, and reject unsupported content rather than logging or silently transforming it.
For the bounded Core evidence contract, the adapter will use the Interactions API request types documented by Google: image for inline PNG/JPEG/WEBP data and document for inline PDF data, with the extraction instruction positioned before the media part.6 The adapter will use a strict timeout, no browser-facing key, and no URL or file-upload retention outside the Core-controlled lease window.
Phased adapter plan¶
| Phase | Scope | Required controls |
|---|---|---|
| 0 — Current | Synthetic demo data only | Locked adapter; human review; no Gemini key or live evidence |
| 1 — Synthetic Gemini evaluation | Isolated fixtures only | Paid project/key stored server-side, strict JSON schema, redacted logs, budget limit, deterministic medication matching, evaluation dataset, and no Core clinical writes |
| 2 — Compliance gate | Decision before any live evidence | Provider/product coverage review, data residency decision, contractual review, threat model, retention policy, and audited approval record |
| 3 — Controlled live pilot | Explicitly authorized evidence references | Core dispatch/outbox, short-lived access, private adapter, no document bytes in the OCR Ops database, mandatory human confirmation, confirmed-only Core receipt, monitoring, and rollback |
What is needed before Phase 1¶
- Confirmation that Phase 1 will use synthetic fixtures only. The implementation will send no patient-originated evidence to the Gemini Developer API.
- An evaluation contract: schema for extracted medication strings and document context, expected abstention behavior, acceptance thresholds, and a review of false-positive medication candidates.
After that, the adapter can implement the existing ExtractionEngine port with strict structured output, provenance resultSource: "ml", model/version recording, deterministic candidate matching, and mandatory human review. It will remain disabled until governance approval is written.