GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!
Watch the launch videoWatchClinical Treatment Protocol
Decision system that selects personalized medical treatments based on diagnosis, patient characteristics, and risk factors for optimal healthcare outcomes.
Solution
This healthcare decision system determines optimal treatment protocols by evaluating multiple patient-specific factors. It begins by classifying condition severity based on diagnostic measurements, such as blood glucose levels for diabetes or peak flow for asthma. The system then factors in patient demographics, identifying special considerations for elderly, pediatric, or pregnant patients.
Risk assessment is performed by analyzing comorbidities and previous adverse reactions, automatically adjusting treatment intensity and follow-up frequency based on risk levels. The system generates comprehensive treatment protocols that include appropriate medication selection, dosage modifications, monitoring requirements, and follow-up schedules. This ensures treatments are tailored to each patient's unique clinical profile while adhering to evidence-based guidelines.
How it works
The decision graph processes patient information through six key evaluation steps:
- Diagnosis Evaluation: Classifies condition severity and determines baseline treatment approach based on measurement values (HbA1c for diabetes, blood pressure for hypertension, etc.).
- Patient Factor Analysis: Evaluates age and pregnancy status to determine risk category and appropriate dosage modifications.
- Comorbidity Evaluation: Assesses additional health conditions and previous adverse reactions to calculate overall risk level.
- Intensity Determination: Sets the treatment protocol intensity based on the patient's risk profile.
- Follow-up Planning: Establishes appropriate monitoring frequency ranging from weekly to quarterly checkups.
- Treatment Protocol Assembly: Combines all decisions into a final personalized treatment plan with specific instructions for medication, dosing, monitoring, and follow-up care.
Where teams use it
- Primary care clinics for standardized treatment selection
- Hospital systems implementing evidence-based protocols
- Clinical decision support for new practitioners
- Telemedicine platforms for consistent remote care
- Medical training and education simulation
- Rural healthcare settings with limited specialist access
Inside the decision model
Clinical Treatment Protocol ships as a JDM decision graph with 7 nodes, 5 decision tables and 28 rules. Download it, load it into GoRules, and run it as-is on Zen Engine.
Request
inputTwo scalars and a patient object drive the whole graph: diagnosis names the condition, measurement_value carries the diagnosis-specific reading (HbA1c, systolic pressure, or peak flow), and patient holds age plus yes/no strings for pregnancy, comorbidities, and prior adverse reactions.
Sample requestJSON
{
"diagnosis": "diabetes_type2",
"measurement_value": 8.2,
"patient": {
"age": 67,
"is_pregnant": "no",
"has_comorbidities": "yes",
"previous_adverse_reaction": "no"
}
}Diagnosis Evaluation
tableSeverity is read off diagnosis plus measurement_value, with first hit resolving the bands. 'diabetes_type2' splits at readings below 7.0 ('mild_diabetes', 'lifestyle_modification'), 7.0 to 8.5 ('moderate_diabetes', 'oral_medication'), and above 8.5 ('severe_diabetes', 'insulin_therapy'); 'hypertension' maps [140..160) to 'stage1_hypertension' with 'lifestyle_and_monotherapy' and 160 or higher to 'dual_therapy'; 'asthma' inverts the direction since higher peak flow is better, grading above 80 as mild and below 60 as 'severe_asthma' on 'multiple_controllers'. An unmatched diagnosis lands on 'unclassified' with 'standard_care'.
The bands track real guideline structure: an HbA1c below 7.0 is the common glycemic target in type 2 diabetes care, and escalating from lifestyle change to oral agents to insulin follows standard stepwise therapy. The 140 and 160 systolic cutoffs match the stage 1 and stage 2 boundaries used in international hypertension guidance, where stage 2 typically starts on two agents, and the 80 percent peak-flow line sits where asthma action plans draw their green zone; the 60 percent split below it is a model calibration.
| Diagnosisdiagnosis | MeasurementValuemeasurement_value | Severitydiagnosis_severity | BaseTreatmentbase_treatment |
|---|---|---|---|
| 'diabetes_type2' | < 7.0 | 'mild_diabetes' | 'lifestyle_modification' |
| 'diabetes_type2' | [7.0..8.5] | 'moderate_diabetes' | 'oral_medication' |
| 'diabetes_type2' | > 8.5 | 'severe_diabetes' | 'insulin_therapy' |
| 'hypertension' | [140..160) | 'stage1_hypertension' | 'lifestyle_and_monotherapy' |
| 'hypertension' | >= 160 | 'stage2_hypertension' | 'dual_therapy' |
| 'asthma' | > 80 | 'mild_asthma' | 'as_needed_bronchodilator' |
+3 more rows in the downloadable template
Patient Factors
tableAge pairs with pregnancy status here, most specific row first: a patient of 65 or older who is pregnant maps to a 'high' patient_risk_category with 'reduced_dosage', 65 or older otherwise gets 'moderate' and 'standard_elderly', under 18 becomes 'special' with 'pediatric_dosage', pregnancy at any other age yields 'elevated' with 'monitor_closely', and everyone else passes as 'standard' with 'standard_dosage'.
Using 65 as the geriatric line reflects the conventional cutoff in geriatric pharmacology, where reduced renal and hepatic clearance argues for dose caution, and carving out under-18s acknowledges that pediatric dosing is a separate discipline rather than a scaled-down adult dose. Flagging pregnancy for closer monitoring is standard practice given teratogenicity and physiologic changes; the specific category labels are model vocabulary.
| Agepatient.age | Pregnancypatient.is_pregnant | PatientRiskCategorypatient_risk_category | DosageModificationdosage_modification |
|---|---|---|---|
| >= 65 | 'yes' | 'high' | 'reduced_dosage' |
| >= 65 | 'no' | 'moderate' | 'standard_elderly' |
| < 18 | - | 'special' | 'pediatric_dosage' |
| - | 'yes' | 'elevated' | 'monitor_closely' |
| - | - | 'standard' | 'standard_dosage' |
Comorbidity Evaluation
tableComorbidity history and prior adverse reactions form a complete two-by-two grid, so no default row is needed: 'yes' on both has_comorbidities and previous_adverse_reaction returns 'critical' with a 'specialist_consult', comorbidities alone return 'high' with 'modified_treatment', a reaction alone returns 'moderate' with 'additional_monitoring', and 'no' on both returns 'low' with 'standard_approach'.
Escalating a documented adverse reaction plus comorbidity to specialist review mirrors pharmacovigilance practice, since re-exposing a complex patient to a drug class that already caused harm is exactly the situation where protocolized care should hand off to a clinician. The exhaustive grid is also good rule hygiene: every combination is stated explicitly instead of leaking into a catch-all.
| HasComorbiditiespatient.has_comorbidities | PreviousAdverseReactionpatient.previous_adverse_reaction | ComorbidityRiskLevelcomorbidity_risk_level | RiskAdjustmentrisk_adjustment |
|---|---|---|---|
| 'yes' | 'yes' | 'critical' | 'specialist_consult' |
| 'yes' | 'no' | 'high' | 'modified_treatment' |
| 'no' | 'yes' | 'moderate' | 'additional_monitoring' |
| 'no' | 'no' | 'low' | 'standard_approach' |
Intensity Determination
tableA single-column lookup translates comorbidity_risk_level into a care intensity: 'critical' becomes 'urgent', 'high' becomes 'intensive', 'moderate' becomes 'standard', 'low' becomes 'routine', and the blank fallback row emits 'regular'.
Keeping this translation in its own table is a maintainability choice rather than a clinical rule: governance can rename or remap intensity tiers without touching the risk logic upstream, and the fallback guarantees the assembled protocol always carries an intensity value.
| RiskLevelcomorbidity_risk_level | ProtocolIntensityprotocol_intensity |
|---|---|
| 'critical' | 'urgent' |
| 'high' | 'intensive' |
| 'moderate' | 'standard' |
| 'low' | 'routine' |
| - | 'regular' |
Follow Up Determination
tableVisit cadence keys off the same comorbidity_risk_level: 'critical' patients are seen 'weekly', 'high' 'bi-weekly', 'moderate' 'monthly', 'low' 'quarterly', and anything unmatched defaults to 'as_needed'.
Scaling follow-up frequency inversely with risk is the standard shape of chronic-disease management, where stable patients get quarterly reviews and unstable ones weekly contact; the specific cadences here are program-level choices rather than mandated intervals.
| RiskLevelcomorbidity_risk_level | FollowUpSchedulefollow_up_schedule |
|---|---|
| 'critical' | 'weekly' |
| 'high' | 'bi-weekly' |
| 'moderate' | 'monthly' |
| 'low' | 'quarterly' |
| - | 'as_needed' |
Final Treatment Selection
expressionAssembly happens last: protocol_name concatenates base_treatment + '_' + patient_risk_category, and treatment_protocol packages a protocol_id built from that name plus protocol_intensity together with the dosage, risk adjustment, follow-up, and severity fields. With passThrough off, callers receive one self-describing plan object instead of the intermediate scoring fields.
base_treatment + '_' + patient_risk_category{
'protocol_id': `${$.protocol_name}_${protocol_intensity}`,
'base_treatment': base_treatment,
'dosage_instruction': dosage_modification,
'risk_adjustment': risk_adjustment,
'follow_up_frequency': follow_up_schedule,
'severity_level': diagnosis_severity,
'protocol_intensity': protocol_intensity
}Other Healthcare templates
View all templatesPatient Triage System
Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints.
HealthcareClinical Pathway Selection
Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans.
HealthcareMedication Dosage Calculator
Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy.
Make this template
your own.
Load Clinical Treatment Protocol into GoRules, adjust the rules to your policy, and ship it behind your own API.