How general-purpose chatbots differ from clinical decision support systems

General-purpose chatbots and clinical decision support systems

General-purpose chatbots are tools built on large language models that are trained on a very broad body of text and can answer questions on almost any subject. Physicians may use them to recall a concept or get oriented on a topic, which is why they often ask whether these tools can also be consulted about a specific patient.

A clinical decision support system brings together the patient's record, clinical knowledge and rules to give the physician the information needed for a decision about a specific patient. Drug interaction and allergy alerts are its classic examples; AI-assisted systems add the ability to read discharge summaries and reports written as free text and to offer reasoned recommendations. The core difference is this: a chatbot serves general knowledge, while a clinical decision support system serves a decision about a specific patient.

Limits of general-purpose chatbots in clinical use

Because general-purpose tools are not designed around a specific institution's regulations, data and workflow, the following limits arise in clinical use:

• A chatbot does not see the patient's record; it only knows the text typed into it. The history, medications and allergies held in the HBYS (the hospital information system used in Turkish hospitals) do not enter the answer unless they are typed in.
• The tool is not bound to local regulations or the institution's rules. In Türkiye, the SUT (the Healthcare Implementation Communiqué published by SGK, the Social Security Institution), the rules of Medula, SGK's pre-authorization and billing system, and the institution's clinical protocols are not applied consistently within the workflow; for rules that change often, the model's knowledge may be out of date.
• Language models can hallucinate: they can state information that is not grounded in fact or in any source, such as a non-existent article or a wrong dose, in fluent and confident language. The fluency of an answer is no indication of its accuracy.
• The source and rationale of an answer cannot always be verified. The same question can get different answers, a cited source may not support the claim, and what the document says is not kept apart from what the model infers.
• Entering patient information raises a data controller question. Health data is special category personal data under both KVKK, Türkiye's personal data protection law, and the GDPR; patient information entered into a general cloud-based tool leaves the institution and sometimes the country. This use should be assessed in terms of the institution's responsibilities as data controller; the guide on using AI without patient data leaving the institution covers this in detail.
• A conversation held in a personal account leaves no record the institution can audit; which recommendation was relied on cannot be traced later.

These tools remain useful for work that is not specific to a patient; an answer that serves as the basis for a decision about a specific patient, however, must be tied to the patient's record, to current rules and to a verifiable source.

Safe-use principles for physicians

Whichever tool you use, the following principles protect both the patient and the physician:

1. Do not enter identifiable patient information into a tool your institution has not approved. Removing identifiers such as the name and national ID number may not be enough; when a rare diagnosis, age, place and date come together, the patient can still be identified.
2. Use general tools for work that is not specific to a patient, such as recalling a concept.
3. Verify every piece of clinical information, such as doses, drug interactions, contraindications and diagnostic criteria, against the current guideline, the drug's official product information or your institution's protocol; if no source is given, or the cited source does not support the claim, treat the answer as unverified.
4. In a tool your institution has approved, ask questions that test your own judgment; an open question such as “What should I not miss in this patient?” lets you compare the possibilities the tool raises with your own differential diagnosis.
5. Follow your institution's AI use policy; if there is none, consult the IT and data protection (KVKK) units.
6. Record the decision and its rationale in the patient record as your own clinical assessment; do not enter AI output into the record without verifying it.

What sets a clinical decision support system apart

An AI-assisted clinical decision support system may also use a language model; the difference lies in which data, rules and audit arrangements the model is connected to. In a responsibly built system, look for the following:

• The system runs inside the institution. It is installed on the institution's servers or in an isolated cloud environment; the data does not leave, and the institution remains the data controller.
• The system is connected to the patient record and the HBYS; the answer draws on the patient's test results, discharge summaries and reports, and the HBYS does not need to be replaced.
• Every recommendation shows its rationale and source, and the answer shows which information comes from the patient's documents and which is the model's inference.
• Rules run in an auditable rule engine. The rule engine produces the result of rule-based checks such as SUT compliance, and AI explains that result and its rationale.
• Every output can be audited later, so a quality unit or auditor can trace the data and sources behind a decision.
• The model is adapted to the local clinical language and reviewed by physicians; Turkish discharge summary language, ICD-10 coding and SUT terminology should be a domain the model understands.

These are also the questions to ask when assessing a system: where does the recommendation come from, which rule does it rest on, where does the data stay, and who makes the decision.

What Opinion AI does in this process

Opinion AI is a clinical decision support platform for hospitals and health insurers, built on MINA, a clinical AI adapted to Turkish. On the physician's side, the clinical decision platform TIS is added on top of the existing HBYS as an intelligent layer. The patient's visits, lab results, imaging reports, discharge summaries and consultations come together in a single live profile, the patient digital twin, and allergy conflicts, drug interactions and risk signals are screened before a decision is made.

The physician puts the question to MINA with the patient file open, in their own words, as they would ask a colleague. The answer draws on the patient's digital twin and on clinical sources and comes with its reasoning and sources; it shows which information comes from the patient's documents and which is MINA's own inference. The physician confirms, corrects or rejects the suggestion.

The open-weight base model behind MINA has been adapted to Turkish and the clinical language of 14 specialties through continued pre-training (CPT) and specialized by specialty, institution and task with LoRA adapters. Knowledge retrieval runs through agentic orchestration over a clinical knowledge graph (GraphRAG) and draws on 30M+ sources, including PubMed, The Lancet, JAMA and BMJ.

The platform runs on the institution's own servers or in an isolated cloud environment. The data stays inside the institution, the institution is the data controller, and the data the model sees passes through KVKK-compliant masking; Opinion AI does not collect personal data. Rules are evaluated in the rule engine. People make the decision; MINA shows the rationale and source of its recommendation, and every output can be audited. The Physician Ethics and Advisory Board, with physicians from 15 specialties, regularly reviews the model's clinical accuracy and ethical boundaries.

Frequently asked questions

Can I consult a general-purpose chatbot such as ChatGPT about a patient?

You should not consult one with identifiable patient information or in a way that makes its answer the basis for a clinical decision. General-purpose chatbots do not see the patient's record, are not bound to local regulations or the institution's protocols, and can produce fluent but wrong answers; entering patient information into a tool the institution has not approved also means the data leaves the institution. These tools can be used for work that is not specific to a patient; every piece of clinical information should be verified against a primary source, and the physician should make the decision.

What is the difference between a general-purpose chatbot and a clinical decision support system?

A general-purpose chatbot is designed to answer questions on any subject and sees only the text typed into it. A clinical decision support system runs inside the institution on the patient's record and the institution's rules; it shows the rationale and source behind its recommendation, keeps what the document says apart from its own inference, and every output can be audited. The first serves general knowledge; the second serves a decision about a specific patient.

What is an AI hallucination, and why does it matter in clinical use?

A hallucination is when a language model produces information that is not grounded in fact or in any source, in fluent and confident language; a non-existent article or a wrong dose can be written this way. In clinical use, wrong information can directly affect a patient's treatment. To reduce the risk, use systems that tie answers to verifiable sources and keep documents apart from inference, so the physician can check every piece of information against its source.

Is it safe to use a general-purpose chatbot if I remove the patient's name and identifiers?

Removing identifiers reduces the risk, but it may not be enough on its own. When a rare diagnosis, age, place and date come together, the patient can still be identified; because health data is special category personal data under KVKK, Türkiye's personal data protection law, and under the GDPR, this use should be assessed in terms of the institution's responsibilities as data controller. The safer path is to use a tool that the institution has approved and that runs in its own environment.

How should a hospital govern physicians' use of AI tools?

A hospital should have an AI use policy that states which tools may be used for which tasks and which tools patient data must not be entered into. A ban alone is not enough; physicians should also be given an approved tool that runs in the institution's own environment, is connected to the patient record and cites its sources. The IT, data protection and quality units should prepare the policy together with physician representatives.

To assess with us how clinical AI would work in your own HBYS environment, use the POC Request form. For choosing a system, see the guide on criteria for choosing a hospital clinical decision support system; for framing the question well, see the guide on getting a safe second opinion from AI as a physician.