How your phone can know if you qualify for a knee replacement without telling anyone else

Loxation Team

March 7, 2026 - 9 minutes read - 1721 words

How your phone can know if you qualify for a knee replacement (without telling anyone else)

On-Device Clinical Reasoning: How We Built a Fuzzy Ontology for Pre-TKR Surgical Readiness

Should a patient with a BMI of 38, borderline diabetes, and an eight-week weight loss programme behind them be scheduled for a knee replacement? Ask three orthopaedic surgeons and you may get three different answers — not because the evidence is unclear, but because the evidence is graded, conditional, and scattered across guidelines from the AAOS, NICE, and the Canadian Orthopaedic Association. We set out to encode that clinical nuance in a system that runs entirely on a patient’s iPhone, preserves their privacy, and gives both patient and clinician a continuously updated readiness assessment without anyone filling in a spreadsheet.

This post walks through the architecture: a fuzzy description-logic ontology, a graph database, and Apple HealthKit — all running on-device, producing real clinical signal from hardware most patients already carry.

The problem with hard BMI cutoffs

The 2022/2023 AAOS Clinical Practice Guideline for Surgical Management of Osteoarthritis of the Knee is clear: patients with a BMI of 30–39.9 achieve comparable functional outcomes to non-obese patients after total knee arthroplasty. The elevated complication risk (particularly surgical site infection) begins above BMI 40, and even then the AAOS stops short of an absolute contraindication. NICE NG157 takes a similar position for the UK. And in 2025, the Canadian Orthopaedic Association, in partnership with Obesity Canada, published landmark recommendations stating that obesity alone is not a reason to deny patients access to joint replacement surgery.

Yet in practice, many institutions apply hard BMI thresholds — a 2025 survey of California orthopaedic surgeons found 75% use cutoffs, with a mean threshold around BMI 40–41 for knee arthroplasty. The gap between guideline nuance and institutional binary gates is exactly the kind of problem that lends itself to formal reasoning.

Fuzzy EL++ and clinical readiness tiers

In Loxation, we already run a fuzzy EL++ ontology reasoner (Dealer) against an on-device graph database (Rukuzu) for trust scoring in our peer-to-peer mesh network. The architecture is general: an OWL 2 ontology defines signal classes and category hierarchies with fuzzy degree annotations; graph queries assert per-entity signals; the reasoner saturates intermediate concepts and classifies the entity into output categories. We realised the same machinery could classify a patient into surgical readiness tiers.

The pre-TKR ontology we built declares 42 input signal classes across five domains: BMI category (WHO classification), weight management progress (programme completion, percentage weight loss, pharmacotherapy, bariatric history), comorbidity status (diabetes control via HbA1c thresholds, hypertension, OSA, smoking, cardiovascular and VTE risk), lifestyle factors (physical activity, nutrition, psychological readiness, opioid dependence), and knee-specific indicators (Kellgren-Lawrence grade, Oxford Knee Score, conservative treatment history).

These signals feed into intermediate concepts — WeightOptimised, ComorbiditiesOptimised, LifestyleOptimised, ClinicallyIndicated — which in turn map to five output readiness tiers:

ReadyForSurgery (green) — proceed to scheduling
ReadyWithCaution (yellow) — proceed with enhanced perioperative protocols
OptimisationRequired (amber) — structured programme, then reassess
SurgeryNotRecommended (red) — significant modifiable risk factors present
ContraindicationPresent (black) — absolute or relative contraindication

The key insight is that these are not binary gates. Each mapping carries a fuzzy degree annotation using Zadeh (min/max) t-norms. A patient who is Class II obese but has completed a structured weight programme and is clinically indicated might classify as ReadyWithCaution at degree 0.65 — the reasoner’s way of saying “proceed, but the evidence for caution is moderate.” That same patient reaching 10% weight loss shifts to WeightOptimised, and the degree moves to 0.75. The ontology encodes the guideline-aligned gradient that a hard cutoff obliterates.

Independently of the readiness tier, the reasoner also flags specific risks: InfectionRiskElevated (BMI >40 combined with poor glycaemic control, per AAOS), WoundComplicationRisk (obesity plus poor nutrition or anaemia), MechanicalFailureRisk (super-obesity, BMI >50), RapidWeightLossRisk (the COA’s concern about crash dieting causing malnutrition), and PoorOutcomeRisk (sedentary lifestyle combined with unaddressed psychological factors and obesity). Risk flags travel alongside the tier and inform the clinical conversation without overriding it.

The graph: Rukuzu for clinical data

Rukuzu is a Rust-based graph database that we already run on-device for social graph intelligence. For the clinical use case, we defined a parallel schema: Patient nodes with BMI, weight, and readiness scores; Condition nodes (ICD-10/SNOMED coded diagnoses); Procedure nodes (past and planned interventions); WeightProgramme nodes for structured weight management; Assessment nodes for point-in-time lab values and clinical scores; Clinician nodes for the MDT; and Guideline nodes that trace which evidence informed each care decision.

Relationship tables capture the temporal and contextual richness that flat records lose: HAS_CONDITION edges carry the most recent HbA1c and fasting glucose alongside the diagnosis; ENROLLED_IN edges track baseline weight, current weight, percentage loss, and compliance; HAS_ASSESSMENT edges store everything from Oxford Knee Score to PHQ-9 to six-minute walk distance.

Signal mappings — the bridge between graph state and ontology assertions — are Cypher queries that return patient IRIs for the reasoner. For example, ObeseClassII is asserted for any patient whose BMI falls between 35.0 and 40.0. DiabetesControlled requires an active diabetes condition where the most recent HbA1c is below 6.5% and fasting glucose is under 126 mg/dL. The pattern is identical to our trust signal mappings: config-driven, no code changes required to add a new signal.

Where the iPhone comes in: HealthKit as a passive signal source

The practical question is data capture. If the patient has to manually enter weight, blood pressure, and activity levels into an app every week, compliance will fall off a cliff within a month. The answer, for most signals, is that the hardware already exists in the patient’s pocket — or on their wrist.

Of the 42 signal classes in the ontology, 21 can be collected fully automatically from iPhone sensors and paired devices. A Bluetooth smart scale (Withings, Renpho) syncs weight to HealthKit; the app derives BMI from HKQuantityTypeIdentifier.bodyMass and height, classifies it into WHO categories, and asserts the appropriate signal. Weight trend over the programme period gives AchievedWeightLoss5pct and AchievedWeightLoss10pct without the patient thinking about it. A paired blood pressure cuff (Omron, Withings BPM) provides bloodPressureSystolic and bloodPressureDiastolic — a seven-day rolling average classifies hypertension control. A continuous glucose monitor (Dexcom G7, Abbott Libre) streams bloodGlucose samples that, combined with lab HbA1c from Health Records, track diabetes control in near real-time.

Physical activity signals are entirely passive. appleExerciseTime aggregated weekly classifies PhysicallyActive (>= 150 min/week) versus Sedentary (< 75 min/week). Step count and walking distance add context. Gait metrics — walkingSpeed, walkingStepLength, walkingAsymmetryPercentage, stairAscentSpeed — provide continuous functional proxies that supplement the point-in-time Oxford Knee Score. A patient whose walking speed drops below 0.8 m/s or whose asymmetry exceeds 10% is showing objective functional limitation, whether or not they remember to fill in a questionnaire.

Apple Watch extends this further with five additional passive signals: sixMinuteWalkTestDistance as a validated functional capacity measure, restingHeartRate and heartRateVariabilitySDNN feeding cardiovascular risk, and — perhaps most valuably — sleepApneaEvent (watchOS 11+, FDA-cleared), which passively screens for obstructive sleep apnoea during sleep. OSA is a significant pre-TKR comorbidity and is often undiagnosed.

Ten more signals come from Apple Health Records, which connects to hospital FHIR endpoints. Lab results provide HbA1c (LOINC 4548-4), albumin (LOINC 1751-7), and haemoglobin (LOINC 718-7) for malnutrition and anaemia screening. Medication records identify active opioid prescriptions (duration > 90 days triggers OpioidDependent) and GLP-1 receptor agonist prescriptions (semaglutide, tirzepatide) for PharmacologicWeightMgmt. Procedure records flag bariatric surgery history and prior knee interventions.

That leaves just six signals that require active clinical input: Kellgren-Lawrence radiographic grading, VAS pain scores, PHQ-9/GAD-7 psychological screening, definitive nutrition assessment, and the clinician’s judgment that conservative treatment has been exhausted. These are entered by the clinical team — or, for pain and mood, via brief validated questionnaires administered periodically in-app.

Privacy by architecture

Everything described above runs on-device. The Rukuzu graph database lives in the app’s sandboxed storage. The Dealer reasoner runs locally — it is compiled Rust, not a cloud API call. HealthKit data never leaves the phone; the app reads samples, derives signals, writes them to the local graph, and the reasoner classifies. The only thing that could be shared with a clinician (with explicit patient consent) is the output: a readiness tier, a score, and a set of risk flags. No raw weight history, no glucose traces, no medication list — just the classification.

This matters because pre-TKR optimisation programmes are exactly the context where patients may be reluctant to share data. Weight is stigmatised. Mental health screening carries stigma. Medication history is sensitive. An architecture where the reasoning happens locally and only the conclusion is shared — if the patient chooses — removes a significant barrier to engagement.

What comes next

The ontology is designed to be extensible. Adding a new guideline source — say, an institution’s own protocol requiring 5% weight loss before scheduling — means adding signal classes and mapping axioms. No code changes, no app update. The graphBindings config pattern means new graph properties surface in the clinical rules engine by adding a line of JSON.

We are also exploring how Apple’s Foundation Models framework (iOS 26+) could provide a conversational interface over the graph. A patient asking “what do I still need to do before my surgery?” could get a natural-language answer grounded in their actual graph state and the ontology’s classification — not a generic chatbot response, but a reasoned explanation of which signals are present, which are missing, and what moving them would do to their readiness tier.

The pre-TKR weight management pathway is our proof of concept. The architecture is general enough to encode any clinical guideline that can be expressed as conditional classification over patient signals — diabetes management protocols, cardiac rehabilitation pathways, cancer screening criteria. The combination of on-device graph reasoning, fuzzy ontology classification, and passive HealthKit signal collection is, we think, a new design pattern for clinical decision support that respects both the complexity of the evidence and the privacy of the patient.

Loxation assesses conformance with published clinical guidelines and does not constitute medical advice, diagnosis, or treatment.

The clinical ontology, graph schema, and HealthKit signal mappings referenced in this post are available in the Loxation repository. The AAOS CPG for Surgical Management of Osteoarthritis of the Knee (2022), NICE NG157, and the 2025 COA/Obesity Canada Recommendations on Elective THA/TKA in Patients Living with Obesity were the primary guideline sources.