page:blueprints:oral surgery:campaign site:django

Oral surgery: campaign site using Django

A campaign site blueprint for oral surgery built with Django on Ample. Domain schema:

• procedures (code, name, description, anesthesia_options, recovery_days): extractions, implants and corrective surgery;
• pre_op_instructions (procedure_id, instructions, fasting_rules): public preparation guidance;
• post_op_instructions (procedure_id, instructions, warning_signs): public recovery guidance;
• locations (name, address, phone, opening_hours, emergency_line): surgery locations;
• asset_versions (version, cdn_key, published_at): versioned assets served from the CDN bucket.

Public information: procedure catalog with recovery expectations, pre- and post-operative instructions, emergency contact per location. Kept out of scope until handling is reviewed: surgical records and consent forms, medication lists, insurance pre-authorizations. Surgical and medication records are health data; only public guidance belongs here. No compliance is claimed.

Technical basis verified on Django: a versioned, immutable-cached asset uploaded to a published bucket and served from the CDN URL alongside the app's own public HTTPS URL.

Representative Queries

• Oral surgery: campaign site using Django
• Where can I host Oral surgery: Campaign site built with Django?
• I need a genuinely specialized campaign site workflow covering public procedure-category content and referral-contact directory; no clinical referrals.

Infrastructure Requirements

• Compute: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
• CDN: The CDN host serves objects from published buckets. It does not front app compute and is not a cache or key-value store.

Workflow Steps

1. Model the oral surgery domain: Create the tables procedures, pre_op_instructions, post_op_instructions, locations, asset_versions. Extractions, implants, and corrective surgery lives in procedures; keep the sensitive classes (surgical records and consent forms, medication lists, insurance pre-authorizations) out of this schema.
2. Model the campaign's offers and locations as tables with start and end dates.
3. Build the site and publish versioned static assets to the CDN bucket.
4. Collect no personal data on the site itself; hand off to an authorized system.
5. Deploy: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.
6. Verify: Run the pattern self-test(s) from the example (/p/versioned-static-assets) and your own acceptance checks for the oral surgery workflow.

Success Checks

• App responds on its public URL
• Versioned-static-assets self-test from the example

Cost Estimate

• Currency: USD
• Monthly Amount: 5.0
• Basis: Size prices from pricing.toml (loaded by the API)
• Components: 1 app server (s-1vcpu-1gb) at 5.0 monthly

Limitations

• The oral surgery schema and workflow are an original design for this blueprint and were not executed as a separate application.
• No compliance claim is made; only public guidance belongs here.