Prescription Capture & Validation (Optics)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €34/mo; credential: we validate RX format, integrate with EuroOptix

Generated from docs/plan/paid/prescription-capture-validation/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Opticians capture and validate patient prescriptions at checkout using EuroOptix API integration. Online RX capture improves conversion 40% by building customer confidence and reducing transaction friction. This paid pack validates optical prescription format (sphere, cylinder, axis, add, PD) server-side, stores RX history on customer + order records, and provides admin tools for manual override when validation fails.

The problem

Opticians lose sales when customers hesitate to buy online without knowing if the prescription format is correct. Manual RX collection via phone or post-checkout email is slow, error-prone, and breaks the purchase flow. Online shops need to capture RX at checkout, not after.

What it does

• Prescription form at checkout (sphere, cylinder, axis, add, PD fields with validation)
• EuroOptix API integration for format validation against optical standards
• Store prescription on order record + customer record for future reference
• Customer RX history retrieval and display (by prescription, by date)
• Admin RX validation dashboard with pass/fail metrics and validation timestamps
• Manual validation override UI for edge cases or API failures
• Privacy-aware PII handling (patient name, DOB, encrypted storage)
• Webhook notification on RX validation failure
• Audit log of all RX validation attempts (pass, fail, override, deletion)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• RX issuance or prescription generation — opticians cannot sell without a doctor-issued prescription; we validate, not create. Reason: medical liability; we are not a prescriber.
• Patient identity verification against medical records — integrating with doctor databases or patient registries adds HIPAA/GDPR complexity and support burden. Reason: trust boundary; only the merchant can verify their customer.
• Automatic transmission to fulfilment system — RX must be reviewed by staff before sending to lab. Reason: legal liability; labs need human sign-off that RX matches order.

Data model

New table: prescriptions (prescriptionId, orderId, customerId, sphere, cylinder, axis, add, pd, format_valid, validated_at, validation_response). Order schema: add prescriptionId fk. Customer schema: add latestPrescriptionId. Audit log entry per validation. No migration needed if using document storage (blob contains full RX object).

API

• POST /api/prescriptions/validate
• GET /api/orders/{orderId}/prescription
• GET /api/customers/{customerId}/prescriptions
• DELETE /api/prescriptions/{prescriptionId}
• PUT /api/prescriptions/{prescriptionId}/override

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

RX validation dashboard showing recent submissions (pass/fail rate, error types). Manual override UI: admin can mark invalid RX as valid with reason. Customer RX history viewer (sortable by date, searchable by order). Prescription export to CSV for fulfilment or lab hand-off.

The seam — why this is paid

Core owns: order + customer schema extensions, generic form rendering, audit logging, webhook system. Paid pack owns: EuroOptix API credential, validation rules (sphere/cylinder/axis ranges), RX format specs, history UI.

Credential: optical prescription API integration, EuroOptix data validation

Dependencies

• Core order + customer models
• Audit log system
• Webhook system
• EuroOptix API credential (assumption: merchant provides)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• An RX with sphere=1.5, cylinder=-0.75, axis=180, add=1.5 passes validation
• An RX with sphere=invalid_string fails validation with user-facing error
• An RX is persisted on the order record at checkout
• A customer’s RX history shows all previous prescriptions, newest first
• Deleting an RX removes it from history and audit log reflects the deletion with timestamp + user
• An RX validation failure triggers a webhook that merchant can consume
• Audit log shows every validation attempt: [prescriptionId] validated as [pass|fail] by [API|staff] on [timestamp]
• Staff can manually override a failed validation; override reason stored in audit
• RX record includes validation timestamp, API response status, and sphere/cylinder/axis values
• Exporting customer RX history to CSV includes id, date, sphere, cylinder, axis, add, pd, validation status

Risks

Storing RX data creates GDPR liability if deletion is not properly audited (careless wipe loses compliance trail). Transmitting RX to unencrypted EuroOptix endpoint exposes optical details; must use HTTPS. Accepting malformed RX due to bad validation breaks lab processing. Not storing validation timestamp makes audits and disputes unrecoverable. Merchant exposing RX to untrusted third party breaks patient privacy.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.