Patient message triage for clinics, with data kept in Switzerland

Patient message triage means sorting the messages patients send to a clinic (portal messages, emails, contact forms) by how urgent they are, which team should handle them and whether a clinician needs to read them. Laya suggests all three in one API call, with a probability for each, so staff open the right messages first.

A busy practice inbox mixes very different requests: "can I move my appointment?", "I need a repeat prescription", "what does my blood test mean?" and, now and then, a message describing a symptom that should not wait until tomorrow. Today someone at the front desk reads every message in order of arrival and forwards it by hand. The worrying message sits in the same queue as the paperwork until a person reaches it.

Laya takes the message as a state and a small set of typed questions, and returns a typed answer per question: a level on an urgency scale, one department from the list you define, and a probability that a clinician should read it. It never generates text, so it cannot write a reply to a patient or produce medical advice. It can only pick among the options you defined. See hallucination-free decisions for what that does and does not guarantee.

Be clear with your team about the role of the model:

• It is not a medical device and it does not diagnose. Laya Studio is a general text-classification service. Its answers are routing suggestions for an inbox, not clinical assessments, and it gives no medical advice to anyone.
• A human clinician stays in the loop. Messages flagged as clinical, possibly urgent, or answered with low confidence go to a clinician, who decides what happens. The model reorders the queue; it never closes a clinical message on its own.
• Emergencies follow your clinic's policy, not the model. Keep your existing safeguards: an auto-reply telling patients that the inbox is not for emergencies and to contact emergency services, and deterministic keyword rules that always escalate. Treat the model as an extra layer that can raise a message's priority, never as the only check.
• It can be wrong, including confidently wrong. The checkpoints ship over-confident: the model card reports mean ECE of 0.466 before temperature scaling and 0.081 after on the English checkpoint. Measure it on a labelled sample of your own historical messages before relying on it, and keep auditing.

This is human-in-the-loop by design: the model does the sorting so clinicians spend their time on the messages that need clinical judgement.

Patient messages are health data, the kind of text that should not sit in a US AI provider's logs. Laya Studio is built so it does not have to:

• GPUs in Switzerland. The primary inference pool runs on dedicated GPUs located in Switzerland. Every API response tells you where it was processed in the x-laya-region header.
• Swiss-only mode. One switch per workspace (or the x-laya-residency: ch header per request) and requests are only ever answered in Switzerland. If the Swiss pool is unavailable you get an error, never a silent detour abroad.
• Zero content retention. The text and questions you send are processed in memory and discarded when the answer is returned. They are never written to a database or log, and never used to train anything.
• Account data in Zurich. Accounts, API keys (stored only as SHA-256 hashes), credit balances and usage metadata live in a Postgres database in the AWS Zurich region (eu-central-2).
• Minimal metadata, 30 days. For billing and debugging only request metadata is kept (time, status, number of questions, latency) for 30 days. Daily totals are kept for invoicing.
• Encrypted in transit. All traffic uses TLS; the GPU servers accept requests only from the Laya Studio gateway.

Laya Studio is designed to support compliance with the Swiss Federal Act on Data Protection (nFADP, in force since 1 September 2023) and the EU GDPR. A Data Processing Agreement is available on request: privacy@laya.studio. You remain responsible for your legal basis to process personal and health data. Laya Studio holds no formal certification (such as ISO 27001) today and does not sign HIPAA BAAs. Full details: Swiss data residency.

The example on this page uses the three question types:

• urgency is a score question with four ordered levels. The answer includes score, the expected level, so a message split between "urgent" and "emergency" reads as roughly 2.5 instead of snapping to one bucket. Score is the weakest primitive in the published benchmarks (0.372 on SST-5), so use it to order the queue, not as a clinical grade.
• department is a choice question with your own teams as keys and a short description each. Keep an other option so a message that fits nothing has an honest place to go.
• needs_clinician is a noul question with optional true/false descriptions. The model card documents that a noul answer can follow its labels rather than the text (issue #156); if answers look stuck, ask it as a two-option choice with neutral keys.

Tips that matter in a clinic:

1. Send only what the decision needs. The latest patient message and subject are usually enough. Leave out identifiers the model does not need, such as insurance numbers or dates of birth.
2. Write options the way you would brief a new receptionist. Descriptions are read next to the message, so plain, specific wording helps.
3. Multilingual patients are covered by routing. Leave model unset and non-English messages (for example German, French or Italian) are routed to the multilingual checkpoint, which covers 100+ languages. Accuracy varies by language, so test the languages your patients actually write in. See multilingual intake.

In a clinic, the costly mistake is a worrying message left at the bottom of the queue. Set the policy so that every uncertain case moves towards a person:

Choose the actual thresholds on a labelled sample of your own historical messages, after fitting temperatures, and pick them for recall on urgent and clinical messages rather than for accuracy overall. Gate on confidence, not action.act_probability: the model card reports that the act head carries no usable signal yet (issue #185). More on this pattern in act or escalate routing.

Call the /v1/systemone endpoint when a message arrives, with Swiss-only residency requested per call:

curl -s https://api.laya.studio/v1/systemone \
  -H "Authorization: Bearer $LAYA_STUDIO_KEY" \
  -H "Content-Type: application/json" \
  -H "x-laya-residency: ch" \
  -d '{
    "state": {"note": "SYNTHETIC EXAMPLE", "message": "Since my operation the wound is red and I have a fever. Should I come in?"},
    "questions": {
      "needs_clinician": {"type": "noul", "instructions": "Should a clinician read the message in `message`?"},
      "department": {"type": "choice", "instructions": "Which team should handle the message in `message`?",
                     "criteria": {"appointments": "booking or moving an appointment",
                                  "clinical_question": "symptoms, recovery or health concerns",
                                  "other": "none of the other options fits"}}
    }
  }'

Check the x-laya-region response header if you want to log where each message was processed. Do not store the model's answers next to the message in a place with weaker controls than your patient record. Get a key at /signup, see pricing, and read the request reference in the docs.