Choose an integration pattern
Understand which workflows use the public API, which require configuration, and which are designed with Doctronic.
Start with the workflow your product needs. The public API covers the common patient, conversation, appointment, pharmacy, and consultation-document operations. Some delivery and routing behavior is configured by Doctronic. Workflows outside the public contract are designed with your implementation team.
Availability
| Pattern | Availability | What to use |
|---|---|---|
| Patient starts a clinical conversation in your product | Public API | Create a user and chat, then consume the SSE stream from your backend. |
| Your workflow passes prior context into a conversation | Public API | Use conversationPromptContext for chat-level context or messagePromptContext for one turn. |
| Your application reacts to safety or next-step signals | Public API | Handle guardian, conversation.end, skill_code.cta, and related typed events. |
| Your workflow books Doctronic care | Public API | Use the address, appointment, and pharmacy operations where enabled for your integration. |
| Your system receives appointment or artifact updates asynchronously | Configured by Doctronic | Register an HTTPS webhook URL, secret, and event subscriptions with your implementation contact. |
| A separate agent hands work to Doctronic | Backend-mediated | Resolve the user in trusted code, pass relevant context, and return typed outcomes to the calling system. |
| Results are delivered into an EHR, FHIR server, or another clinical system | Co-developed | Define the destination, data mapping, authorization, and operational ownership with Doctronic. |
| Proactive outreach starts from an external trigger | Co-developed | Define the trigger, consent, channel, safety behavior, and return path with Doctronic. |
“Public API” means the operation is present in the published OpenAPI contract. It does not mean that credentials, geography, clinical workflow, or production access are enabled automatically.
Patient-facing conversations
Your frontend sends patient input to your backend. Your backend authenticates the patient, maps the patient to a Doctronic user ID, and calls the Doctronic API. It can relay the documented stream events to the frontend without exposing the organization token.
Use explicit events for product state. Do not infer a safety state, conversation end, or care action from assistant text.
Agent and workflow handoffs
The current public API does not provide delegated agent credentials or a direct agent-to-agent session protocol. A calling agent should invoke a narrow tool in your backend. That backend should:
- Authenticate the caller and resolve the patient.
- Select the allowed Doctronic operation.
- Pass only the context required for the clinical task.
- Enforce the same safety and authorization rules as any other caller.
- Return structured events or documents to the calling system.
See Patient context and handoffs for the current context fields and trust boundary.
Configured and co-developed work
For configured or co-developed capabilities, agree on these items before implementation:
- The patient identity and consent boundary.
- The source and destination of clinical data.
- Required events, documents, and failure states.
- Which system owns patient messaging and escalation.
- Test data, acceptance evidence, rollout controls, and operational contacts.
Contact your Doctronic business or implementation contact to confirm availability for a specific workflow.