Back to Search View Original Cite This Article

Abstract

<jats:p>Patient-facing medical information software is typically built one disease at a time: each new condition requires a bespoke application, with its own data model, user interface, and safety scaffolding. This approach does not scale to the breadth of human disease. Orphanet, the reference catalogue of rare conditions, alone describes on the order of six to seven thousand clinically distinct rare diseases, and broader clinical terminologies enumerate tens to hundreds of thousands of codeable entities; no hand-built, per-disease portfolio can realistically span that space. This report presents the Medical App Generator, a single SwiftUI application for macOS and iOS in which the disease is not hard-coded but is instead a selectable, user-enterable parameter that re-skins the entire application from a declarative configuration object. We describe the configuration schema (disease metadata, comorbidities with etiological-driver categories and linking mechanisms, numerical metrics with field-importance metadata, symptoms, blood tests, and a treatment database), the runtime architecture that binds it to a reactive user interface, and a free-text disease-resolution layer that loads curated content for known conditions and a functional blank template for any other name entered. A central contribution is the application's safety architecture. The system is positioned as informational rather than advisory: it presents AI-assisted, literature-derived content as structured input for a licensed clinician, never as a diagnosis or a personalized prescription. Treatments are withheld behind a combined medical, safety, warranty, liability, and intellectual-property notice that the user must explicitly accept; a dosage reference is gated behind required safety fields and never computes a patient-specific dose; and a dedicated condition (Long COVID and its synonyms) is deliberately blocked and redirected. We map these design choices to the United States Food and Drug Administration's criteria for non-device clinical decision support and to the published literature on clinical decision support systems and on the reliability of large language models in medicine. We report a transparent coverage analysis: five diseases ship with curated data, one is intentionally inert, and all other names resolve to an empty but fully navigable template. We conclude that configuration-driven generation, paired with conservative, explicit safety gating, is a defensible pattern for patient information tools, and we discuss its limitations, including the gap between representative and exhaustive clinical content and the unresolved question of formal validation.</jats:p>

Show More

Keywords

safety disease clinical medical application

Related Articles

PORE

About

Connect