> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hi-doctor.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Développer avec Hi-Doctor et l'IA

> Un prompt prêt à coller, le protocole du questionnaire conversationnel et les règles qu'un assistant doit respecter.

Hi-Doctor est conçu pour être piloté par un assistant IA. Le
[connecteur MCP](/fr/mcp/connect) expose l'ensemble du parcours de soin d'un
patient sous forme d'outils, dont un questionnaire qui peut être rempli comme
une conversation plutôt que comme un formulaire.

Cette page s'adresse à qui développe cet assistant.

## Collez ceci dans votre prompt système

<Tip>
  Copiez ce texte tel quel dans le prompt système de tout assistant connecté à
  Hi-Doctor. Il encode les règles ci-dessous, ce qui vous évite d'avoir à les
  répéter. Il est fourni en anglais ; conservez-le tel quel.
</Tip>

```text theme={null}
You have access to Hi-Doctor, an online medical service, through its MCP
connector. You are acting on behalf of a patient who has connected their own
account.

WHAT YOU CAN DO
- Complete a medical questionnaire with the patient, one question at a time.
- Get them a payment link for a consultation or treatment plan.
- Read their consultations, prescriptions, orders and payments.
- Send and read messages to and from their medical team.
- Track progress: log and correct weight, injections and daily notes.
- Manage their plan: cancel, reactivate, or open the billing portal.
- Pull a renewal forward (early order) — only with the payment permission.

HOW TO RUN A QUESTIONNAIRE
1. Call hidoctor_questionnaire_start with the category the patient wants.
2. Ask the patient the question exactly as it is returned. Do not rephrase
   clinical wording, and do not merge several questions into one.
3. Present the returned options as the choices. Send back the option's `value`,
   not the label you showed.
4. Call hidoctor_questionnaire_answer with their answer. It returns the next
   question. Repeat until status is "ready_to_submit".
5. Use hidoctor_questionnaire_review to read the answers back to the patient
   before submitting. Use hidoctor_questionnaire_back to change one.
6. Call hidoctor_questionnaire_submit.

RULES
- Never invent, assume or infer a medical answer. If the patient has not
  answered, ask again. "I don't know" is a real answer. If none of the options
  fits, read them out and let the PATIENT choose — never choose for them, and
  never narrow the list down on their behalf.
- Never give medical advice, and never suggest a medication or a dose. A
  registered doctor decides those after reviewing the questionnaire.
- If the questionnaire comes back ineligible, say so plainly and do not try
  other answers to get a different result.
- Before anything that costs money or cancels a plan, tell the patient exactly
  what will happen and get an explicit yes.
- Cancelling a plan takes effect at the end of the paid period, not
  immediately. Say that.
- An early order is IRREVERSIBLE: it creates the renewal consultation now and
  uses up the one early order allowed this period. Explain that and get an
  explicit yes before calling it.
- A prescription or invoice link is a medical document. Give it only to the
  patient. If the result says delivery is signed_redirect, the link opens
  WITHOUT signing in — never repeat it anywhere shared and do not store it.
- If the patient describes severe or sudden symptoms — chest pain, difficulty
  breathing, suicidal thoughts, a severe allergic reaction — stop and tell them
  to contact their local emergency number. Do not continue the questionnaire.
```

## Le protocole du questionnaire conversationnel

<Steps>
  <Step title="start">
    `hidoctor_questionnaire_start` avec un `category_slug` (`weight-loss`,
    `hair-growth`, `sexual-health`, etc.). Renvoie la première question sans
    réponse, ainsi que `answered_count` et `applicable_total` pour que vous
    puissiez afficher la progression.

    Si le patient avait déjà un questionnaire en cours, il reprend là où il
    s'était arrêté.
  </Step>

  <Step title="answer, en boucle">
    `hidoctor_questionnaire_answer` enregistre une réponse et renvoie la question
    **suivante**. C'est le serveur qui décide de la suite : l'arborescence est
    donc gérée pour vous, et vous n'évaluez jamais une condition vous-même.

    Les réponses sont fusionnées, pas remplacées. Rien n'est perdu d'un appel à
    l'autre, et le patient peut s'interrompre puis revenir plus tard.
  </Step>

  <Step title="relire et corriger">
    `hidoctor_questionnaire_review` renvoie toutes les réponses données jusque-là
    sous une forme lisible. `hidoctor_questionnaire_back` revient à la question
    précédente afin qu'une réponse puisse être modifiée.

    Modifier une réponse peut fermer une branche. Dans ce cas, la réponse de
    l'outil liste `dropped_question_keys` : les réponses devenues sans objet et
    supprimées. Signalez-le si cela a de l'importance pour le patient.
  </Step>

  <Step title="submit">
    `hidoctor_questionnaire_submit` renvoie un `outcome` :

    | Valeur                   | Signification                                                    |
    | ------------------------ | ---------------------------------------------------------------- |
    | `submitted`              | Envoyé pour examen par un médecin.                               |
    | `ineligible`             | Cliniquement inadapté. C'est un résultat normal, pas une erreur. |
    | `covered_by_active_plan` | La formule en cours du patient le couvre déjà.                   |
  </Step>
</Steps>

### La forme des réponses

La question vous indique comment y répondre. Lisez `kind` :

| `kind`                      | À envoyer                                                |
| --------------------------- | -------------------------------------------------------- |
| `single`, `select`          | `value: "<option value>"`                                |
| `multi`, `multi-with-input` | `values: ["<option value>", …]`                          |
| `input`                     | `values: { "<field name>": <value>, … }`                 |
| `confirm`                   | `value: "understood"`                                    |
| `option-input`              | `option_inputs: { "<option_input_key>": "<free text>" }` |

Les nœuds de relance portent une chaîne `answer_instructions` qui indique
exactement où doit aller la valeur. Suivez-la.

## Les règles ci-dessus ne sont pas imposées techniquement

Hi-Doctor ne peut pas savoir si une réponse vient du patient ou a été déduite
par l'assistant. Rien dans l'API ne le vérifie.

<Warning>
  L'intégrité du dossier clinique dépend du respect de ces règles par votre
  assistant. Un assistant qui complète une réponse plausible enverra le
  questionnaire avec succès — et un médecin prescrira à partir de là. Traitez
  « ne jamais inventer de réponse » comme une contrainte stricte de votre prompt
  système, et non comme une suggestion.
</Warning>

Ce que le serveur *impose*, en revanche, c'est l'éligibilité.

## L'éligibilité est décidée par le serveur

Les contre-indications, le seuil d'IMC, la limite d'âge et le contrôle du pays
pris en charge sont appliqués au moment de l'envoi du questionnaire — ni par
l'assistant, ni par le site.

<Warning>
  N'essayez pas de présélectionner un patient, et ne relancez pas un questionnaire
  avec des réponses modifiées après un résultat `ineligible`. Ce contrôle existe
  pour protéger les personnes, et le contourner mettrait un patient en danger.
</Warning>

## Les pièges qui vous attendent

<AccordionGroup>
  <Accordion title="Envoyez les valeurs des options, pas les libellés">
    Les libellés sont du texte destiné aux humains et sont traduits dans la
    langue du patient. `value` est l'identifiant stable attendu par le serveur.
  </Accordion>

  <Accordion title="Le questionnaire est dans la langue du patient">
    Le texte des questions revient dans la langue enregistrée sur le profil du
    patient. Posez-les dans cette langue.
  </Accordion>

  <Accordion title="Le paiement a lieu sur Stripe, pas dans la conversation">
    `hidoctor_checkout_create` renvoie un lien. Ne demandez jamais de données de
    carte bancaire : vous n'avez aucun moyen de les recueillir, et le demander
    habitue les patients à confier leur numéro de carte à des agents
    conversationnels.
  </Accordion>

  <Accordion title="Le suivi des progrès est réservé à la perte de poids">
    Toutes les autorisations sont accordées lors d'une connexion patient
    normale, paiement compris. Mais le journal de progression est construit
    autour du poids, des injections et d'un plan d'injection : il n'est donc
    **disponible que pour le traitement de la perte de poids**, et pas pour les
    formules croissance des cheveux ou santé sexuelle.

    Appelez `hidoctor_progress_status` avant de proposer un suivi. Si un outil
    est totalement absent, c'est que le patient a refusé cette autorisation au
    moment de la connexion : dites-le plutôt que d'imaginer un contournement.
  </Accordion>

  <Accordion title="Le poids est d'une entrée par jour ; les notes et les injections non">
    Enregistrer un poids pour une date remplace l'entrée de cette journée. Les
    notes et les injections s'ajoutent : les enregistrer deux fois en crée deux.
  </Accordion>
</AccordionGroup>

## Sans MCP

Si vous n'utilisez pas de client MCP, les mêmes capacités sont disponibles via
l'[API REST](/api-reference/introduction) — y compris
l'[inscription par programmation](/api-reference/signup), afin qu'une interface
conversationnelle puisse aussi créer le compte.