A retrieval engine first. A language model second.
Here is exactly how an encounter moves through TriagePath — from what the nurse types to what ends up in the chart.
Nurse describes the encounter
Plain-language description of what the patient reported — symptom, duration, relevant history.
Deterministic protocol match
The system searches your approved protocol library and finds the specific document. No free reasoning yet.
The model turns it into guidance
Its only job here is language — converting matched protocol content into a clear, readable answer.
Guidance + draft SOAP note
A citeable answer and a note draft, ready to review and copy into the record.
Retrieval happens before the model reasons about anything — that is what keeps every answer traceable to a real document instead of the model's general training.
What actually happens during setup week.
A week is not a vague promise — here is what fills it.
Protocol migration
Your existing protocols — written, verbal, or somewhere in between — get structured into the library the system reads from.
Configuration & testing
Encounter categories, urgency tiers and staff sign-in are set up and run through real test encounters.
Staff training
A short walkthrough with your nursing staff — the interface is built to need very little of this.
Go live
Real patient calls, with close attention paid to the first days before we step back. This is also when your free week starts — not before.
The one thing we actually need from you
Your protocols — written, verbal, or somewhere in between. That's the whole dependency, no matter what kind of practice you run. Everything else on this list, we build.
What TriagePath deliberately does not do.
A narrower, more conservative design is a feature in a clinical setting. Auditable beats clever.
It does not reason freely from general medical knowledge — every answer starts from a protocol your practice approved.
It does not replace clinical judgment — it is decision support for the nurse, not a diagnosis engine.
It does not store patient identifiers or PHI in its usage metrics — only operational data like encounter type and resolution time.
Built with a clinical setting's constraints in mind.
BAA-covered processing
Clinical queries are processed through Azure OpenAI Service inside a Microsoft tenant covered by a HIPAA Business Associate Agreement.
No PHI in stored metrics
What's logged is operational — nurse, channel, resolution steps. No names, no identifiers, no records.
Your protocols stay yours
Each practice's protocol content stays its own — never shared with another client's deployment.
Role-based access
Single sign-on and role-based permissions control who can see what.