Patient experience

Doctronic API calls must originate from your backend. A web or mobile client can display the conversation and send patient input through your application, but it must not receive the organization token.

Required interface states

Plan explicit behavior for:

• Starting and reconnecting a conversation.
• Streaming an assistant message.
• A guardian event.
• A call to action from skill_code.cta.
• A conversation that ends without a consultation document.
• Consultation documents that are still processing.
• Appointment state changes.
• A recoverable stream error or network interruption.
• An event name your current client does not recognize.

Use event types and API responses for these states. Do not parse assistant text to decide whether to escalate, end a conversation, or book care.

Brand and attribution

Patient-facing implementations must use the Doctronic name and attribution approved for the integration. Confirm the current lockup, placement, and wording with your Doctronic implementation contact before launch. Do not remove or alter required attribution.

Your product can retain its own navigation, account, and support patterns around the Doctronic experience. Agree on which system owns each patient message, error state, and support handoff.

Accessibility

• Announce streamed content without repeatedly moving keyboard focus.
• Provide visible status text in addition to color or animation.
• Keep safety messages and calls to action available to assistive technology.
• Support keyboard navigation and sufficient target sizes on mobile.
• Let users recover from a dropped connection without losing the visible transcript.
• Test long clinical content, large text sizes, reduced motion, and narrow screens.

Data in the client

Send only the information the interface needs. Do not place the organization token, webhook secret, unrestricted clinical documents, or internal routing details in client-visible state, analytics, crash reports, or logs.