Browser
The authorized user begins and reviews the workflow.
Security without badge theater
Trust should be inspectable.
Molaris creates clinical drafts, keeps the clinician in control, and can send approved content to Open Dental. This page maps the current boundaries plainly.
This is an explanatory system map—not a certification, audit report, or promise that a particular agreement is automatically included.
The shortest accurate view of the system, from practice browser to approved destination.
Where information moves.
Vercel serverless
Server-side requests proxy connected services.
Supabase
Application rows use practice-scoped access policies.
Configured models
OpenAI handles transcription; OpenAI or Anthropic can draft notes.
Open Dental
Only the relevant user action can initiate writeback.
Generation, approval, and filing are deliberately separate states.
The model drafts. The clinician decides.
Once approved, the record locks. A later correction creates a separate pending amendment; the signed original remains unchanged.
If Open Dental writeback does not complete, the signed content remains available in Molaris and the failure is reported instead of being presented as success.
These application controls complement—not replace—practice device, workforce, consent, and access policies.
Current control points.
- Practice scoping
- Supabase row-level security limits application records to the signed-in practice context.
- Session and recovery data
- Browser authentication and periodontal recovery state are tab-scoped and cleared at sign-out; clinical context is not carried in Open Dental query parameters.
- Provider credentials
- Open Dental, model-provider, email, SMS, and billing secrets stay in server-side environment variables rather than browser code.
- Signed-note integrity
- Approved sections are database-guarded against mutation. Approval and amendment events are append-only audit entries after the included migration is applied.
- Referral acknowledgment
- Opening an email link is read-only. A human must press Confirm receipt, preventing mail scanners from acknowledging a referral.
- Open Dental outcome
- The interface distinguishes the preferred destination, an explicit fallback, and a failed request.
The exact provider set depends on the features and model configuration a practice uses.
Connected providers, by job.
VercelHosting and serverless request handling.
SupabaseAuthentication, application records, storage, and row-level access controls.
OpenAITranscription and, when configured, note drafting.
AnthropicNote drafting when selected.
ResendReferral and application email.
TwilioOptional patient-form SMS.
StripeCheckout and billing status.
Open Dental APIDestination for user-approved clinical workflows.
Before sending protected health information, confirm the provider configuration, retention terms, contractual requirements, and any business associate agreements required for your practice. Review the Privacy Policy and Terms; executed agreements control over this page.
These are deployment questions, not fine print to defer until after launch.
Confirm before clinical use.
- Retention
- Ask for the periods that apply to audio, transcripts, drafts, operational logs, and backups in your configuration.
- Deletion
- Confirm what can be deleted, timing, backup limitations, and the separate status of content already written to Open Dental or another system.
- BAA scope
- Confirm availability, covered services, parties, subprocessors, and effective date before using the product with PHI.
- Incident process
- Ask for the current reporting route, response process, and contractual notification terms.
Inspect the approval boundary yourself.
The demo uses fictional data and exposes draft, review, approval, locked-note, amendment, destination, and failure states.
Open the live demo →