Work / PROJECT 06

Comorbidity Management: Routing Risk Alerts into Outpatient Referral and Inpatient Consultation

Built on a hospital's existing clinical systems, the platform uses confirmed clinical rules to flag comorbidity risks, delivers alerts to the physician workstation, outpatient text messages and specialist consultation, and records how physicians respond.

Iterating October 25, 2026 Rule-based alerts Physician workstation Outpatient SMS Comorbidity consultation

3 initial scenarios

High cardiovascular risk, hyperuricemia and gout, infection management

2 handoff paths

Outpatient text referral; inpatient workstation alerts and comorbidity consultation

Rule-based alerts

How phase one identifies risk; LLM-assisted identification is a later direction

On this page8 sections

Summary　Comorbidity risks often sit in the lab and imaging results of a single visit. The hard part is what happens next: who verifies the signal, who tells the patient, and who takes it on. A general hospital’s comorbidity management platform builds on its existing clinical decision support system, hospital information system and SMS platform. Phase one relies on clinical rules: outpatients receive a text suggesting a specialist visit, inpatient alerts appear in the physician workstation where a comorbidity consultation can be requested directly, and handling choices are recorded. This article covers the roles, the two paths, what was in place by September 2026, what comes next, and how to judge whether it works.

After a risk is spotted, who takes it on

Hospitals are organised by specialty, yet many patients carry several chronic conditions or risk factors at once. A clinic visit for a digestive complaint or an admission for surgery can produce results that call for another specialty’s assessment.

Before this platform, such signals were handled roughly like this:

Detection depended on experience: on rounds or in clinic, physicians read through lab and imaging results and judged by experience, with no shared identification criteria.
Consultations were filled in by hand: physicians opened consultation orders manually and typed the purpose and invited department, with no standard template.
Records were hard to count: consultation notes carried no “comorbidity” category, so it was hard to tell afterwards which consultations had been triggered by comorbidity.
Follow-up lived in each department’s own notes: what happened after a consultation was tracked manually inside departments.

Outpatient care adds one more gap: some results come back after the patient has left. The information sits in the system; neither the patient nor the relevant specialty knows about it.

So the product is not about “finding more abnormalities”. It is about giving each risk alert a clear recipient, a place to act and a record of what was done.

Positioning: a handoff chain inside existing systems

The platform does not add a separate system. It reworks workflows on top of the hospital’s clinical decision support system (CDSS), the hospital information system (HIS) physician workstation and the SMS platform: the CDSS identifies risks by rule, the HIS puts alerts in front of physicians and carries the consultation, and the SMS platform notifies outpatients who have already left. The medical affairs department raised the requirement, the information department assessed and implemented it, and relevant clinical departments took part.

Role	What they do in the system	Judgement and responsibility
Attending or ward physician	Sees the alert at the workstation, checks the reason, requests a comorbidity consultation or defers	Judges clinical relevance and decides whether to consult
Comorbidity specialist	Receives the consultation, reviews records and results, writes an opinion; in outpatient scenarios, views the triggered list	Specialist assessment and advice; contacts the patient when needed
Outpatient	Receives a reminder text with a booking link	Decides whether to go for further assessment
Medical affairs and IT teams	Provide and maintain rules and message content; query triggers, notifications and consultations	Rule definitions, process quality and ongoing improvement

The initial scenarios fall into three groups, and each follows a different path:

Coverage of the three initial scenarios: high cardiovascular risk is outpatient only; hyperuricemia and gout cover outpatient and inpatient; infection management is mainly inpatient; glucose management is a later direction — All three are called "comorbidity management", yet their outpatient coverage, inpatient coverage and follow-up reminders differ.

Glucose management appears in the overall plan and the rule list but is a later extension, not one of the initial scenarios.

From a rule match to clinical action

The flow has five steps: rule identification → alert delivery → physician verification and choice → outpatient referral or inpatient consultation → records and statistics.

Comorbidity management flow: after rule identification, an outpatient text path and an inpatient consultation path; physicians judge and act; every step is recorded — Green steps are done by the system; orange steps are physician judgement and action.

The most important part of the diagram is the division of labour:

The system: finds candidate risks using confirmed rules; delivers alerts to the right person and screen; pre-fills consultation details; sends review reminders where the scenario calls for them; records each step.
The physician: judges whether the alert holds and whether it matters for this patient; decides to consult, defer or act otherwise; carries out specialist assessment and later treatment decisions.

A rule match only means “worth checking”; it is not a diagnosis. Trigger criteria are provided centrally by medical affairs and confirmed clinically. They include lab values, imaging conclusions, diagnoses recorded in the chart and specific medications.

Comorbidity rule maintenance screen listing cardiovascular and gout rules with triggers, suggested handling and departments — Rule maintenance screen (Chinese interface): each rule states the trigger, the suggested handling and the outpatient clinic or consulting department. Editors and internal codes are covered; thresholds shown are configuration examples, not clinical standards.

Outpatient: reminder texts and specialist referral

The outpatient path covers cases where the risk signal appears after the patient has left.

Rules identify an outpatient who meets a scenario’s criteria.
The SMS platform sends a reminder naming the specialty for further assessment, with a booking link.
The relevant specialty sees the triggered list and key values in its back office and contacts the patient when needed.
The patient visits the specialty, where the specialist takes a history, orders tests and makes the call.

The text is a reminder and a pointer, not a diagnosis. The current template tells the patient that the hospital system places them in a risk group for a named condition and suggests a timely visit to the named specialty for further assessment, with a booking link; it does not state a diagnosis. The requirements also call for logging each send and passing failed sends to the managing department.

Sample outpatient comorbidity reminder texts for high cardiovascular risk and gout, suggesting further assessment at the relevant specialty — Sample outpatient texts in Chinese: high cardiovascular risk (left) and gout (right). The hospital name and booking short link are covered.

Inpatient: workstation alerts, comorbidity consultation and recorded decisions

Inpatients have a ward physician and continuous care, so alerts go into the screens physicians open every day.

Alerts reach the workstation. The CDSS pushes the alert and the suggested department to the HIS. When a physician opens the patient’s record for routine work, a pop-up states the trigger and the suggested department and asks whether to request a consultation.

Comorbidity alert pop-up in the inpatient physician workstation stating the trigger and suggested department and asking whether to request a consultation — Comorbidity alert pop-up in the inpatient physician workstation (test environment, Chinese interface).

One less form to fill in. Once the physician chooses to consult, the alert content fills the consultation purpose and the suggested department fills the invited department. The physician adds the question the consultation should answer and sends it; the record carries a “comorbidity” flag.

Consultation request with the purpose filled from the alert and the invited department pre-filled — Consultation request (test environment): purpose and invited department are pre-filled; the clinical summary is added by the physician. Location and hospital are covered.

Deferring requires a reason. If the physician decides no consultation is needed for now, they can defer and give a reason. The design offers preset options such as the patient declining enrolment, the patient’s current condition not being suitable, or a transient abnormal value; any other reason must be typed in, at least 10 characters long.

Dialog for the reason not to proceed: choose a preset reason or type another reason of at least 10 characters — Reason for not proceeding (test environment): choose a preset reason, or type at least 10 characters for "other".

The specialist takes over. The invited department reviews records and results, writes its opinion, and can filter its own list for comorbidity consultations.

Reminders follow the scenario. In infection management, the specialist is reminded three days after enrolment to review the patient’s condition, treatment and medication and to consider adjusting the plan. Gout progresses over a longer period, so a three-day review adds little and is not set. In the initial design, high cardiovascular risk follows the outpatient path only.

Three-day comorbidity reminder asking the specialist to review the patient's current condition, treatment and medication — Three-day review reminder (test environment). The patient identifier is covered.

The “defer” branch matters. It accepts that a physician’s judgement can differ from the rule, and keeps the reason for later rule tuning.

Illustrative scenario: two handoffs

The following is fictional, describes no real patient, and is not medical advice.

Outpatient: A patient leaves after a clinic visit to another specialty. Results issued that day meet the high-cardiovascular-risk criteria. The patient receives a text suggesting further assessment in cardiology, with a booking link; cardiology also sees the patient on its back-office list. Whether to go is the patient’s decision; once there, assessment and treatment are up to the specialist.

Inpatient: Another inpatient’s medication record triggers the infection management scenario. The ward physician sees the pop-up on opening the record, decides a specialist opinion is needed, requests a consultation from the pop-up and adds the question for the specialist. The specialist reviews the record and writes an opinion; three days later, the system reminds the specialist to look at the patient again. If the ward physician judges the trigger to be a transient fluctuation, they can defer and record the reason instead.

Five modules, each closing a gap

Module	What it does	Gap it addresses
Comorbidity rules and alerts	Medical affairs provides trigger criteria; the CDSS identifies and pushes alerts	No shared identification criteria
Outpatient reminder texts	Sends patients who have left a suggested specialty and booking link	No one tells the patient after they leave
Comorbidity consultation request	Starts from the alert, pre-fills reason and invited department, adds a comorbidity flag	Purpose and department typed by hand
Consultation management and review reminders	Specialist reviews and writes an opinion; review reminders where the scenario calls for them	No tracking after the consultation
Comorbidity queries and statistics	Queries consultations by the comorbidity flag; shows trigger, handler and action	Comorbidity consultations could not be filtered or counted

Inpatient comorbidity report listing scenario, triggered rule, whether a comorbidity consultation was requested, reason type and whether the consultation took place — Inpatient comorbidity report (August 2026 data, Chinese interface): each row records the scenario, the triggered rule, whether a comorbidity consultation was requested, the type and reason for not proceeding, and whether the consultation took place. Patient identity, department, staff and dates are covered.

Taken together, the value comes down to three concrete things: alerts reach someone who can act, instead of sitting in a report; starting a handoff costs less, with pre-filled consultations and a named specialty plus booking link for patients; and the process can be checked, so managers can see where a risk stopped moving.

It is just as important to say what it does not do: it does not diagnose for physicians, does not order treatment automatically, and does not guarantee that patients attend.

What is in place and what comes next

According to the September 2026 build report, the platform entered trial operation in August–September 2026 with three scenarios open. Its capabilities in that period were rule-based alerts, outpatient text referral, inpatient comorbidity consultation with recorded decisions, and comorbidity consultation queries. This section reflects that period and is not a live status report.

Capabilities in place as of September 2026, gaps named in the build review, next directions, and the separate candidate identification and physician labelling prototype — Left: capabilities running at the time. Middle: gaps named in the same review. Right and bottom: plans and exploration.

The same report names four gaps: alerts rely on single-value thresholds and disease conditions, with broad severity grading and repeated reminders; there are no rules for combinations of co-existing conditions, so some cases are missed; inpatient action relies mainly on consultation, without joint rounds, medication reconciliation, or nutrition, rehabilitation and nursing coordination; and the virtual shared ward, cross-department permissions and informed consent are still to be built, with co-management review and follow-up not yet connected.

The corresponding directions are all still plans: adding glucose and other conditions and extending into post-discharge care; refining severity grading and calibrating thresholds; using large language models to help recognise combinations of conditions, working alongside rules rather than replacing them; building cross-department co-management; and connecting patient-side services such as medication reminders, self-reported values and follow-up booking.

A separate exploration: a prototype for candidate identification and physician labelling

False alerts, missed cases and broad grading can only be corrected by physician judgement. A separate prototype explores how to capture that judgement.

In its design, rules generate candidate labels and supporting evidence from clinical data, which enter a review queue. After reviewing a patient summary, timeline and source evidence, the physician confirms, rejects, modifies, marks the information as insufficient or defers, and can add labels the rules missed. Rejections require a reason, such as mistaking past or family history for a current condition, or a single lab value being insufficient. Each review saves a data snapshot and the rule version, so rules and future models can be evaluated offline on the same basis.

Its boundaries need to be clear:

It is a different product from the hospital platform. The requirement specification of August 2026 was still an MVP review draft, and the definitions of the first suggested labels still needed clinical sign-off.
The available material covers the prototype’s design and development. It does not show a connection to real hospital data, routine clinical use, or a medical large language model trained or deployed.
The prototype outputs candidate labels, not formal diagnoses; it does not generate treatment plans or modify the hospital’s source data.

How to judge whether it works

Alert counts, text counts, consultation numbers and visits are the easiest figures to report. They are useful, but each answers a question about one step.

Five layers of evaluation: identify, deliver, take over, visit, outcome; each answers a different question — The first four layers show whether the process works; only the fifth is clinical effect, which needs its own evaluation.

A few things are best agreed in advance:

Separate patients from episodes, and keep the definition consistent.
Set a baseline: some patients would have seen the specialty anyway, so recalled visits are not automatically an increase; business volume and charges are not clinical benefit either.
Look at the reasons for deferring: if they cluster, the rule definition probably needs adjusting.
Sample for missed cases: looking only at flagged cases cannot show who was missed.
Design outcome evaluation separately: changes in complications, length of stay or readmissions need a dedicated evaluation with a comparison, a time frame and clear data sources.

Until those evaluations are done, the careful statement is this: the platform has put risk alerts into outpatient and inpatient workflows; whether it improves patient outcomes is a question for the data.