Products / Clinical
In developmentASSISTIVE INTELLIGENCEFOR CLINICALDECISIONS.
- Domain
- Clinical decision support
- Status
- In development
- Available for care
- No
The problem
Hard cases are hard because the context is scattered
- Complete context
- The relevant history exists, but assembling it for one decision is manual work done under time pressure.
- Option comparison
- Several treatment paths may be defensible. The comparison between them usually happens in someone’s head and leaves no record.
- Risk identification
- Interactions and contraindications are knowable, but only if every relevant item of context was actually in view.
- Transparent reasoning
- A recommendation without visible reasoning cannot be challenged, taught from, or reviewed later.
- Human judgement
- The parts that need clinical judgement should stay with the clinician. Support means removing the assembly work, not the decision.
- Traceability
- Months later, someone may need to see what was known and what was considered at the time.
Intended workflow
How it is designed to run
- 01
Patient context
History, current presentation and relevant prior treatment, assembled rather than searched for across systems.
- 02
Relevant medical information
Retrieval narrowed to what bears on this case, with the source of each item kept attached to it.
- 03
Option generation
Treatment paths that are actually defensible for this patient, not a generic list.
- 04Gate
Contraindication and risk checks
Interactions, comorbidities and known risks tested against the specific context.
- 05
Ranked considerations
Options ordered with the trade-offs made explicit, including what would change the order.
- 06
Explanation
Why each option ranked where it did, in language a clinician can interrogate and challenge.
- 07Human
Clinician decision
The clinician chooses. The system records what was shown, what was chosen and when.
Human control
Control is the design, not a setting
- 01The decision stays with the clinician
- The system ranks and explains. It does not select a treatment, and it has no route to act on a patient record on its own.
- 02Every recommendation is explainable
- A ranking that cannot be explained is a defect, not an output. If the reasoning cannot be shown, the option should not be presented.
- 03Uncertainty is surfaced, not smoothed
- Where the context is incomplete or the evidence is thin, that is stated on the option rather than hidden behind a confident number.
- 04Actions require defined authority
- Anything that writes to a clinical record or reaches a patient sits behind an approval by a person with the authority to give it.
- 05History is available for review
- What the system received, what it proposed and who decided, retained so a case can be reviewed long after the appointment.
- 06Escalation is a designed path
- When context is missing or a contraindication is detected, the intended behaviour is to stop and escalate, not to proceed on a best guess.
The same control mechanisms are used across every Barion product. How guardrails and observability are engineered.
Intended users
Who this is being designed with
- Primary care physicians
- Specialists working complex cases
- Clinical decision boards
- Healthcare institutions
Intended audiences. No deployment has taken place.
Status
Where development has actually reached
- Designed
- The decision model, the intended workflow and the control requirements above.
- Being built
- The reasoning, ranking and explanation layers on Barion Core, which are shared with products already running.
- Not started
- Clinical validation, regulatory assessment, and any deployment into a care setting.
- Open now
- Design partnership with clinicians and institutions willing to shape the comparison and the guardrails against real practice.
Discuss a clinical AI partnership
We are looking for clinicians and institutions who want to shape this against real practice. Design partnership, not deployment.


