About

The "rules-first, then LLM" strategy works well in ClinCalc / ExClinCalc, with the shared characteristic that rules are explicit, boundaries are clear, and judgments can be binarized (e.g., KDIGO staging, 12 critical drug interactions). The LLM only acts as a translator, not a clinical decision-maker.

My current hypothesis: this strategy generalizes to scenarios where rules are explicit and the LLM is a translator, but does not generalize to scenarios where rules are fuzzy and the LLM must decide (e.g., differential diagnosis, symptom synthesis). In the latter, rule coverage is necessarily incomplete and the LLM cannot be given free rein due to hallucination risk ── this remains an unresolved tension.

Open question: Can we design a "graded trust" architecture that lets the LLM operate with controlled freedom where rules don't cover ── e.g., a second LLM as a fact-consistency meta-checker, or RAG using clinical guidelines as a dynamic knowledge base? This is the first direction I want to deepen in graduate school.

ExClinCalc's 14 tables / 29 RLS policies run smoothly in the demo environment, but lack quantitative evaluation under realistic load. Literature on RLS performance mostly stops at "it'll be slow" or "just add an index" anecdotes — there's no systematic benchmark.

My current observation: RLS has minimal impact on point queries (e.g., "fetch my patient X"), but performance noticeably degrades on cross-table JOIN + large-row scenarios. I used EXISTS subqueries + STABLE function caching + index reinforcement, but this is engineering experience, not a principled design method.

Open questions: (a) How do you design a reproducible RLS performance testing framework that compares across schema scales? (b) How do you formally verify policy completeness (e.g., mutation testing or SMT solver to prove no row bypasses any policy)? On security, I did multi-role demo-account cross-testing, but that's not a penetration test. Grad-school plan: real clinic deployment + benchmark + formal verification.

The Cloudflare Workers + Supabase architecture runs smoothly for both my systems, but the decision "edge over region-locked" was based on intuition, not quantification. Edge computing intuitively benefits the consumer-side ClinCalc (global low latency), but is questionable for the clinical-side ExClinCalc:

• Regulations may require data residency ── global edge nodes may violate GDPR / Taiwan's PDPA
• Healthcare isn't high-frequency trading ── 50ms latency improvement is imperceptible in a clinic; audit consistency / disaster-recovery predictability matter more
• Free-tier limits could become an SLA risk ── what if a real clinic has a traffic spike and gets throttled?

Open question: Can we build a "medical-software deployment architecture decision matrix" that quantifies regulation / privacy / latency / cost / availability / disaster recovery into comparable dimensions? This direction may straddle medical-informatics management and cloud architecture ── it's the direction I'm least certain about but most want to clarify.