The Medical App Generator: A Configuration-Driven Architecture for Disease-Agnostic Patient Information Applications with Embedded Safety, Provenance, and Clinician-Handoff Design

1. Introduction

1.1. Background and Motivation

The delivery of trustworthy medical information to patients is one of the enduring problems of health informatics. Patients increasingly arrive at clinical encounters having already consulted digital sources, and the quality of those sources varies enormously. Well-constructed tools can improve preparation for appointments, support shared decision-making, and help patients organize the questions and history they wish to discuss. Poorly constructed tools can mislead, can substitute for professional judgment, and can produce harm that is difficult to trace. The design space between these outcomes is narrow, and it is governed as much by what a tool refuses to do as by what it offers.

Most patient information applications are built for a single condition. A team identifies a disease of interest, assembles domain content, designs an interface around that content, implements the safety and disclaimer language appropriate to it, and ships a standalone product. When a second condition is addressed, much of this work is repeated. The data model is frequently re-implemented; the user interface is re-laid-out; and, most consequentially, the safety scaffolding is re-created, often inconsistently. The result is a portfolio of applications that share little and that each carry their own latent defects.

This report describes an alternative built and refined over an extended development effort: a single application in which the disease is a parameter rather than a constant. The Medical App Generator (hereafter “the Generator”) holds a library of declarative configuration objects, one per curated disease, and renders its entire interface — pages, fields, terminology, content, and even its decorative iconography — from whichever configuration is currently selected. Crucially, the disease is not limited to a fixed menu: the user types a disease name, and the application resolves it to curated content when it recognizes the name and to a functional, empty template when it does not. The safety scaffolding is implemented once, in the shared shell, and therefore applies uniformly to every disease the Generator can express.

1.2. The Scale Argument

The motivation for a generator, rather than a portfolio, is fundamentally a question of scale. The number of recognized human diseases is large and depends on how finely conditions are individuated, but every credible accounting places it far beyond what any hand-built collection of single-disease applications could cover. Orphanet, the principal curated reference for rare diseases, describes on the order of 6,000 to 7,000 clinically distinct rare conditions; one widely cited analysis of the Orphanet database reports descriptions of 6,172 clinically unique rare diseases [1], while more recent characterizations of the same resource describe coverage exceeding 7,000 conditions across more than thirty classification categories [2]. These figures count rare diseases alone. When common conditions are included, and when one turns to general clinical terminologies rather than rare-disease registries, the totals grow by one to two orders of magnitude: contemporary diagnostic ontologies enumerate tens of thousands of codeable disease entities, and comprehensive clinical terminologies catalog hundreds of thousands of clinical concepts.

The implication is direct. If even the rare-disease subset numbers in the thousands, then a strategy of building and maintaining one application per disease is not merely inefficient; it is infeasible. A portfolio approach can address tens of conditions, perhaps low hundreds with substantial institutional investment, but it cannot approach the full space. A generator changes the unit of production from the application to the configuration. Adding a disease becomes a matter of authoring a data object, not of building software. This does not make the content problem disappear — authoring accurate clinical content for thousands of diseases remains a major undertaking — but it decouples the content problem from the software-engineering and safety-engineering problems, which the generator solves once.

1.3. Problem Statement

The Generator is therefore designed to answer a specific question: can a single, safety-constrained application shell present structured, disease-specific information for an open-ended set of conditions, while (a) supplying genuinely curated content for a working subset, (b) degrading gracefully to an empty but navigable template for conditions it does not yet cover, and (c) enforcing a uniform safety posture that prevents the tool from crossing the line from information into advice or prescription? This report describes the architecture that answers this question, the clinical-content methodology that populates it, the safety mechanisms that constrain it, and an honest accounting of what it does and does not currently cover.

1.4. Contributions

This report makes the following contributions, each of which is developed in a later section:

• A configuration-driven architecture (Section 4 and Section 5) in which a single declarative object fully determines a disease-specific patient information application, including pages, fields, content, terminology, and iconography.
• A free-text disease-resolution layer (Section 4.4) that accepts any disease name, binds known names to curated content, and produces a functional blank template for unknown names, making the set of expressible diseases open-ended rather than fixed.
• A field-importance and elimination model (Section 5.3 and Section 8.2) that classifies every input as crucial, useful, or unnecessary, hides the unnecessary, and progressively removes fields once symptoms are recorded, focusing the user only on what affects treatment, dose, or safety.
• A layered safety architecture (Section 7) comprising an explicit pre-treatment acceptance gate, a dosage reference that is gated on safety inputs and never computes a patient-specific dose, a deliberately blocked condition with redirection, at-rest protection of the local profile, and verbatim medical, warranty, liability, and intellectual-property notices.
• A transparent coverage analysis and clinical-content methodology (Section 6 and Section 10), including the structured elicitation prompts used to generate comorbidity, laboratory, and prevention content, an explicit distinction between representative and exhaustive data, and per-disease counts.
• A mapping (Section 7.6) of the application’s design to the United States Food and Drug Administration’s criteria for non-device clinical decision support software.

Added in this revision (design rationale): a treatment-availability and treatments-tried model (Section 5.5, Section 5.6 and Section 8.6) that records what is obtainable and what a patient has already tried without benefit and re-ranks accordingly; a redesigned treatment record format (Section 5.5 and Section 8.5) that unifies provenance, evidence maturity, availability, and tried status in one card; an expanded severity-implication model (Section 5.3) that makes recorded severities drive field elimination, ranking, and escalation prompts; a local-data-protection mechanism (Section 7.7); and a disease-prevention page (Section 6.4 and Section 8.1, Appendix C) presented before patient identifiers.

1.5. Organization

Section 2 reviews related work in clinical decision support, mobile health regulation, generative artificial intelligence in medicine, and configuration-driven software. Section 3 states the design goals, requirements, and explicit non-goals. Section 4 and Section 5 describe the architecture and the configuration schema in detail. Section 6 describes the clinical-content methodology, including the elicitation prompts and the new prevention content. Section 7 presents the safety architecture and its regulatory mapping. Section 8 describes user interaction and workflow. Section 9 covers implementation. Section 10 offers an evaluation and discussion, including a coverage analysis and a candid statement of limitations. Section 11 addresses ethical, legal, and regulatory considerations. Section 12 outlines future work, and Section 13 concludes. Appendices provide the full configuration schema, the elicitation prompts, and per-disease content tables.

2. Related Work

The Generator sits at the intersection of four bodies of work: clinical decision support systems, the regulation of mobile and software-based medical tools, the use of generative artificial intelligence in medicine, and configuration- or model-driven software engineering. We review each and then identify the gap the Generator addresses.

2.1. Clinical Decision Support Systems

Computerized clinical decision support systems (CDSS) have a history reaching back to the 1980s and have become a routine component of electronic health records [3]. The literature on their effectiveness is substantial and, importantly, conditional: decision support improves care most reliably when specific design features are present. Meta-regression of 162 randomized trials identified features such as automatic provision of support within clinician workflow, provision of recommendations rather than mere assessments, and delivery at the time and location of decision-making as predictors of effect [4]. A meta-analysis of controlled trials found that CDSS produce measurable but generally modest absolute improvements in the targeted processes of care [5], and an earlier systematic review reached compatible conclusions about the variability of effect [6]. Adoption is itself a challenge: a systematic review and meta-regression of CDSS uptake found that clinician use is far from guaranteed and is shaped by usability, trust, and workflow fit [7].

Two themes from this literature inform the Generator directly. First, decision support that informs and is transparent about its basis is more defensible, and more likely to be used appropriately, than support that asserts conclusions. Second, the canonical guidance for effective decision support — often summarized as a set of pragmatic “commandments” emphasizing speed, fit to workflow, and the delivery of actionable information rather than raw data [17] — applies as much to patient-facing tools as to clinician-facing ones. The Generator is not a CDSS in the regulated sense; it is patient-facing and explicitly non-advisory. But it inherits the literature’s central lesson: a tool that organizes and surfaces relevant information, while leaving judgment to a professional, occupies a safer and more useful position than one that attempts to decide.

2.2. Mobile Health Applications and Their Regulation

Mobile health applications are numerous and uneven in quality, which motivated the development of structured quality instruments such as the Mobile App Rating Scale, covering engagement, functionality, aesthetics, and information quality [20]. On the regulatory side, the United States Food and Drug Administration (FDA) has articulated a risk-based policy under which it focuses oversight on software whose malfunction could harm patients, while exercising enforcement discretion over lower-risk tools [8]. The 21st Century Cures Act amended the statutory definition of a medical device to exclude certain clinical decision support software from device regulation [10], and the FDA’s guidance on clinical decision support software elaborates the criteria distinguishing non-device decision support from regulated software [9].

The criteria most relevant to a patient information tool are that the software inform rather than direct clinical decisions, that it not acquire or analyze signals to provide a specific patient-specific output that replaces professional judgment, and that the basis for any information it presents be transparent and independently reviewable [9]. The Generator was designed with these criteria in view; Section 7.6 maps its features against them explicitly. We do not claim regulatory clearance or assert a regulatory status, which is a determination reserved to the relevant authority; we describe a design intent consistent with the published criteria.

2.3. Generative Artificial Intelligence in Medicine

Large language models (LLMs) have demonstrated striking competence on medical knowledge tasks, in some settings encoding clinical knowledge well enough to approach or exceed human benchmarks on examination-style questions [11], and in others producing patient-facing responses that human raters judged favorably against physician responses on dimensions such as empathy [12]. Adapted models have outperformed experts on constrained tasks such as clinical text summarization [13]. These results establish that generative models can produce useful medical text.

The same literature is unambiguous about the risks. Models hallucinate — producing fluent, plausible, and incorrect statements — and they can be factually wrong in ways that are difficult for non-experts to detect. Even on text summarization, careful evaluation finds non-trivial hallucination and omission rates [15]. More fundamentally, recent work argues that current models lack the metacognition required to know when they do not know, undermining naive reliance on them for medical reasoning [14], and dedicated safety benchmarks have been developed precisely because medical safety is not guaranteed by general competence [16]. The consensus that emerges is not that generative models are unusable in medicine, but that their outputs must be treated as drafts requiring expert verification, never as authoritative conclusions.

This conclusion is the load-bearing premise of the Generator’s safety architecture. The application uses AI-assisted, literature-derived content, and it states this fact prominently and repeatedly. It never presents that content as advice, and it routes the user toward a licensed clinician for any decision. The design treats the documented unreliability of generative models not as an obstacle to be hidden but as a fact to be surfaced and managed.

2.4. Configuration-Driven and Model-Driven Software

The idea that an application’s behavior can be derived from a declarative model rather than hand-coded for each case is well established in software engineering, where model-driven approaches raise the level of abstraction from code to domain models and generate or interpret implementations from them [18]. Modern declarative user-interface frameworks extend this spirit to the presentation layer: Apple’s SwiftUI describes interfaces as functions of state, so that a change in the underlying data is reflected automatically in the rendered view [19]. The Generator combines these ideas in a narrow, domain-specific way: a single declarative configuration per disease serves as the model, and a SwiftUI shell interprets it into a complete, reactive application. This is not a general model-driven platform; it is a focused application of the pattern to the patient-information domain.

2.5. Gap Analysis

The reviewed literatures leave a specific gap. CDSS research concerns clinician-facing, often regulated systems and does not address patient-facing, disease-agnostic generation. Mobile-health and regulatory work establishes the rules a patient tool should respect but does not prescribe an architecture for spanning many diseases safely. The generative-AI literature establishes both the promise and the danger of model-derived medical content but is largely silent on the product-level scaffolding that would make such content safe in a consumer tool. Model-driven engineering supplies the generation pattern but not its specialization to clinical safety. The Generator’s contribution is to occupy this gap: a configuration-driven, patient-facing architecture that is open-ended across diseases and that embeds, in its shared shell, the conservative safety posture the other literatures imply.

3. Design Goals, Requirements, and Non-Goals

3.1. Functional Requirements

The Generator was developed against the following functional requirements, refined iteratively over the course of the project (design rationale):

• The disease shall be a runtime parameter, enterable as free text, not a compile-time constant or a fixed menu.
• A recognized disease name shall load curated content; an unrecognized name shall load a navigable but empty template under that name.
• Each disease shall be expressible through a single declarative configuration object covering metadata, comorbidities, metrics, symptoms, blood tests, prevention measures, and treatments.
• The application shall present, per disease, structured pages for prevention, patient information, clinical metrics, comorbidities, symptom severity, a symptom summary, blood tests, treatment candidates, follow-up notes, and questions for the patient’s clinician.
• Content shall be searchable along multiple fields and modes.
• The application shall be able to assemble a summary suitable for handoff to the patient’s clinician.
• The application shall record which treatments the patient has already tried, and whether each was ineffective or not tolerated, and shall re-rank the remaining candidates so that already-failed interventions are de-emphasized.
• The application shall present, for each treatment, an availability status describing whether the intervention is currently obtainable, limited, investigational, or withdrawn.
• The application shall present a disease-prevention page, ahead of patient identifiers, describing how the selected condition may be avoided or its onset reduced.

3.2. Non-Functional Requirements

Non-functional requirements (design rationale):

• Single-artifact deployability: the application shall build from one self-contained source file, simplifying maintenance and review in the author’s workflow.
• Cross-platform operation on macOS and iOS from a shared codebase.
• Reactive consistency: any change to the underlying state shall be reflected automatically in the interface.
• Graceful degradation: absence of content for a disease shall never produce an error state, only an explicit, informative absence.
• Local-first data handling: patient-entered data shall remain on the device unless the user explicitly initiates a handoff, and shall be protected at rest.

3.3. Safety and Ethical Requirements

Safety requirements were treated as primary and non-negotiable (design rationale, informed by [9,14,16]):

• The application shall present information, not medical advice, and shall state this prominently.
• Treatment content shall not be reachable until the user has explicitly accepted a combined medical, safety, warranty, liability, and intellectual-property notice.
• The application shall never compute or display a patient-specific drug dose; any dosing content shall be reference-level and gated on the completion of required safety fields.
• AI-assisted content shall be labeled as such wherever it appears.
• Treatment availability and tried/ineffective status shall be presented honestly, so that neither an unavailable intervention nor one a patient has already failed is surfaced as though it were a fresh, obtainable option.
• The local patient profile shall be protected at rest, and no patient data shall leave the device except through an explicit, user-reviewed handoff.
• At least one condition (Long COVID and its synonyms) shall be deliberately blocked and redirected, demonstrating and enforcing scope boundaries.

3.4. Scope and Explicit Non-Goals

Equally important are the things the Generator deliberately does not attempt (design rationale):

• It is not a diagnostic engine and does not output diagnoses.
• It is not a prescribing tool and does not compute personalized doses.
• It does not transmit patient health information autonomously; a clinician handoff composes a message that the user reviews and sends.
• It does not claim exhaustive clinical content; bundled data are representative samples at the level of drug classes and major associations.
• The prevention page describes general, literature-derived measures for discussion with a clinician; it is not a personalized prophylaxis plan.
• It does not claim regulatory clearance; it describes a design consistent with published non-device criteria.

Rare Disease Distribution by Organ System

Preliminary reference report — Med App Gen disease-to-organ mapping project

Purpose

This report summarizes the current best available data on how the recognized universe of rare diseases distributes across organ systems and body parts. It is intended as a preliminary reference ahead of a planned, more granular organ-level extraction from Orphadata’s clinical classification files, which will also incorporate a 1–4 severity scale derived from Orphanet’s disability dataset.

Scope and data source

The figures below come from Orphanet’s rare disease nomenclature, July 2025 release (dataset version 1.3.42 / 4.1.8), as reported in a peer-reviewed description of the Orphanet nomenclature published on medRxiv. Orphanet’s inventory covers 6,527 distinct rare disorders (9,784 if disorder groups and subtypes are included separately). This is the rare-disease universe specifically — common diseases such as diabetes, hypertension, and most cancers are not catalogued in Orphanet and are not reflected in these counts.

Each disease in Orphanet is assigned one “preferential” classification for counting purposes, even though many diseases have manifestations across several organ systems. The table below uses that primary classification, regrouped from Orphanet’s specialty-based categories onto an organ/body-part axis.

Disease counts by organ / body system

Organ / body system	Disease count	% of total
Whole-body / multi-system	3,342	51.2%
Brain & nerves	1,096	16.8%
Skin	392	6.0%
Bone	352	5.4%
Eye	242	3.7%
Immune system	209	3.2%
Endocrine glands	196	3.0%
Blood	183	2.8%
Other specialties (not individually mapped)	515	7.9%
Total	6,527	100%

A majority of rare diseases (51.2%) fall into categories that are inherently whole-body or multi-system rather than tied to a single organ — conditions such as Long COVID would sit in this category rather than under any single organ heading. The breakdown of that category:

Whole-body / multi-system subcategory	Disease count
Developmental defects (embryogenesis)	2,109
Neoplastic (cancers)	496
Inborn errors of metabolism	398
Infectious	176
Systemic / rheumatologic	163

Key finding: multi-system prevalence

Beyond primary classification, Orphanet separately tracks every organ system each disease affects (not just its primary one). Under that fuller accounting, 67.7% of rare diseases are multi-system — touching more than one organ classification — versus 32.3% that are cleanly single-system. Under this fuller accounting, the neurologic count rises to 2,492 diseases touched (vs. 1,096 as primary classification), developmental-defect involvement rises to 2,793, ophthalmic to 868, and skin to 835. This reflects that many rare diseases present with symptoms across several organs even when assigned one “headline” classification.

Limitations

Several caveats apply to this data and should inform how it is used:

• Rare-disease scope only. This is not a count of all human disease — common conditions are excluded entirely, and any total near 8,000 for “all human diseases” does not correspond to a single audited source.

• Specialty-based, not strictly anatomical. Orphanet’s classification files group by clinical specialty (e.g., “cardiac,” “urogenital”), which only approximately maps to anatomy — “urogenital” bundles kidney with reproductive organs, for example.

• Primary-classification counts undercount multi-organ involvement. The 51.2% whole-body figure and the fuller 67.7% multi-system figure (previous section) are both legitimate but answer different questions — use the one that matches the intended use case.

• Severity not yet incorporated. This report reflects disease counts only. A planned follow-up will merge in Orphanet’s disability dataset (SeverityDisability field: low / moderate / severe / complete, mapped to 1–4) once the underlying script has been run against live Orphadata.

Next steps

The organ groupings above were derived from classification-level aggregate statistics. A companion Python script (orphadata_organ_severity_table.py) has been prepared to pull the full per-disease dataset directly from Orphadata’s XML classification files and disability dataset, which will allow: (1) exact per-organ disease counts rather than specialty-level approximations, (2) a severity score (1–4) per disease, and (3) a full list of which diseases are multi-organ, with the specific organs each one touches. Running that script is the next step toward a production-ready dataset for the Med App Gen disease-to-organ mapping feature.

Body Parts

As shown by the next figure, diseases affect either the whole body, several or one body part.

Rare Disease Distribution by Organ / Body System

This report summarizes a disease-to-organ mapping analysis built on the Orphanet rare disease classification, developed to support the disease-specific clinical workspace architecture in Med App Gen. The goal was to reorganize Orphanet’s disease-focused classification into an organ/body-part–first structure, so that clinical workspaces can be generated per organ system rather than per disease category.

Background and Data Source

Orphanet is the reference portal for rare diseases and orphan drugs, maintained by INSERM and an international consortium of over 40 countries. Its July 2025 release lists 9,784 active clinical entities, of which 6,527 are distinct disorders after excluding subtypes, groups of disorders, and etiological subgroups counted separately (Lucano et al., 2025).

Orphadata, Orphanet’s structured data platform, publishes this classification as XML downloads under a CC-BY 4.0 license. Two products were used in this analysis:

• product3 (classifications) — one XML file per medical classification hierarchy, mapping each disorder to its parent classification (e.g., “Rare cardiac disease,” “Rare skin disease”). These 34 hierarchies were remapped to 20 organ/body-part categories and 5 whole-body/multi-system categories for this project, since several hierarchies (e.g., cardiac and cardiac malformations) correspond to the same organ.
• product9 (disability) — disorder-level severity/disability annotations (SeverityDisability field: low / moderate / severe / complete / unspecified), mapped to a 1–4 numeric severity scale for future integration into Med App Gen’s workspace generation logic.

A Python script (orphadata_organ_severity_table.py) merges both products and outputs per-organ disease counts, average and maximum severity, and a full disease-to-organ lookup table. This script must be run locally, since the Orphadata servers are outside this environment’s network allowlist.

Disease Distribution Across Classifications

Across the 6,527 distinct disorders in the July 2025 Orphanet release, the twelve largest primary linearized classifications account for the substantial majority of entries. The remaining seventeen classifications (cardiac, renal, hepatic, respiratory, gastroenterological, and others) each individually contain fewer than 100 primary-linearized disorders.

Classification	Linearized (n)	% of n
Developmental defects (embryogenesis)	2,109	32.3%
Neurological	1,096	16.8%
Neoplastic	496	7.6%
Inborn errors of metabolism	398	6.1%
Skin	392	6.0%
Bone	352	5.4%
Ophthalmic	242	3.7%
Immune	209	3.2%
Endocrine	196	3.0%
Haematological	183	2.8%
Infectious	176	2.7%
Systemic/rheumatologic	163	2.5%

A key structural finding: 67.7% of Orphanet disorders are classified in more than one hierarchy, reflecting the fact that most rare diseases are multi-system conditions rather than single-organ conditions. When disorders are counted by every classification they appear in (rather than only their primary classification), the counts rise substantially — for example, neurologic involvement rises from 1,096 (primary) to 2,492 (multi-classified), and developmental involvement from 2,109 to 2,793. This is the central reason the organ/body-part remapping for Med App Gen tracks all organ involvements per disease, not just a single primary classification.

Representative Diseases by Organ / Body System

The table below pairs each of the 25 organ/body-system categories used in the accompanying figure with one real, correctly-classified example disorder from that category in Orphanet’s classification. These are illustrative examples chosen to anchor each category to a recognizable condition — not an exhaustive list of the disorders within each category.

Head & Neck

1	Neurological	Friedreich ataxia
2	Ophthalmic	Retinitis pigmentosa
3	Ear, nose & throat	Pendred syndrome
11	Maxillo-facial	Treacher Collins syndrome
12	Odontological	Amelogenesis imperfecta

Chest

4	Cardiac	Danon disease
13	Respiratory	Primary ciliary dyskinesia
14	Circulatory	Hereditary hemorrhagic telangiectasia
20	Thoracic surgical	Poland syndrome

Upper Abdomen

15	Hepatic	Wilson disease
5	Endocrine	Multiple endocrine neoplasia type 1
6	Immunological	Wiskott-Aldrich syndrome
7	Haematological	Fanconi anemia

Lower Abdomen / Pelvis

16	Renal	Alport syndrome
17	Gastroenterological	Familial adenomatous polyposis
10	Abdominal surgical	Hirschsprung disease
19	Urogenital	Prune belly syndrome
18	Gynaecological/obstetric	Mayer-Rokitansky-Küster-Hauser syndrome

Limbs & Skin

8	Skin	Epidermolysis bullosa
9	Bone	Osteogenesis imperfecta

Whole-Body / Multi-System

21	Developmental	Beckwith-Wiedemann syndrome
22	Neoplastic	Li-Fraumeni syndrome
23	Metabolic	Gaucher disease
24	Infectious	Whipple disease
25	Systemic/rheumatologic	Behçet disease

Limitations

• Categories marked as containing fewer than 100 disorders in the source summary do not yet have an individually confirmed exact count; exact per-category figures require running the local Orphadata script against the current XML files.
• The organ/body-part categories used here are a project-specific remapping of Orphanet’s 34 native classification hierarchies, chosen to fit an organ-first workspace model; they are not an official Orphanet grouping.
• Severity scoring (1–4, from Orphanet’s SeverityDisability field) has been designed but not yet merged into the organ counts in this version of the report; that integration is the next step.

Next Steps

• Run orphadata_organ_severity_table.py locally against current Orphadata XML files to produce exact per-organ counts and severity scores.
• Integrate the resulting organ_counts.csv and disease_organ_map.csv into Med App Gen’s disease-specific workspace generation logic.
• Extend the 1–4 severity scale annotation across all organ categories, replacing placeholder “<100 (exact pending)” labels with confirmed counts.

4. System Architecture

4.1. Overview

The Generator follows a clean separation between a declarative domain model, a reactive runtime state, and a view layer that renders the former through the latter. At the center is the configuration object, which fully describes a disease. A single application store holds the currently selected configuration together with the patient’s working data and the currently selected page. The view layer is a navigation shell whose sidebar and detail panes are generated from the configuration’s page list and content. Because the framework is declarative, mutating the store — by selecting a different disease or editing a field — automatically re-renders the affected views without imperative update code.

Three properties follow from this structure. First, the disease is genuinely a parameter: switching configurations replaces the content, terminology, and iconography of the entire application in one operation. Second, the safety scaffolding lives in the shell, not in any configuration, so it cannot be omitted for a particular disease. Third, new diseases require no new views: an authored configuration is sufficient.

4.2. The Configuration Model

The configuration type aggregates everything that distinguishes one disease from another: a display name and subtitle; a short description of the condition’s core signals; a flag indicating whether the condition is psychological (which suppresses the decorative biochemical animation); an icon kind that selects the disease-specific illustration; the list of pages the application should present; and content collections — comorbidities, numerical metrics, symptoms, blood tests, prevention measures, and treatments. Each content collection is a list of small, self-describing records, detailed in Section 5. The configuration is a value object: it holds data and no behavior beyond derived conveniences, which keeps each disease’s definition declarative and inspectable.

4.3. Runtime State

Patient-entered data live in a separate, observable profile object distinct from the configuration. The profile holds the run and patient identifiers, the values of numerical metrics, the set of toggled comorbidities, the set of flagged blood tests, symptom severities, the set of treatments the patient has already tried together with an outcome flag (ineffective or not tolerated), a recovery log, follow-up notes, the clinician-handoff fields, and the user’s filter preferences. Keeping the profile separate from the configuration is deliberate: the configuration is fixed reference content, while the profile is mutable user state, and the two have different lifecycles. The profile is serializable so that user state can persist across sessions; new fields added during development are decoded defensively so that older saved data remain loadable, and the serialized profile is protected at rest as described in Section 7.7.

An application store binds a configuration and a profile together and mediates between them. When a disease is selected, the store installs the new configuration and resets the profile’s content-bound dictionaries to defaults derived from that configuration — initializing, for example, one metric entry per metric the configuration defines. The store also houses the recommendation logic that ranks treatment candidates against the patient’s currently active symptoms, filter settings, and the set of treatments already tried without benefit.

4.4. Disease Resolution from Free Text

The defining interaction of the Generator is that the user types a disease name rather than choosing from a list. A resolution routine interprets the entered text. It first attempts an exact, case-insensitive match against the names of the curated configurations; failing that, it attempts a loose containment match in either direction, so that abbreviations and partial names resolve to the intended disease. If neither matches, the routine constructs a generic configuration on the spot: a value object bearing the entered name, a neutral subtitle, the default molecule iconography, the standard page list, and empty content collections. The application then renders this template exactly as it would render a curated disease, except that the content pages display an explicit notice that no curated dataset is bundled for the entered condition.

This design makes the set of expressible diseases open-ended. The number of diseases the Generator can present is therefore not the number of bundled configurations; it is unbounded in principle, limited only by the user’s ability to name a condition. The number for which it presents curated content is a separate, smaller figure, reported transparently in Section 10. The deliberate block on Long COVID and its synonyms is implemented at this layer: the entered name is tested against a synonym set, and a recognized synonym routes the entire detail pane to a redirection notice regardless of the rest of the configuration.

4.5. View Layer and Navigation

The interface is a two-pane navigation structure. The sidebar contains the disease entry field and the list of pages drawn from the active configuration; the detail pane renders the selected page. The page list is data, not code: adding or reordering pages — for example, inserting the new prevention page ahead of patient identifiers — is a matter of editing the configuration’s page collection, and the detail pane dispatches on a page identifier to the corresponding view. Because the framework re-renders as a function of state, selecting a page or editing a value updates the display without manual refresh logic.

4.6. Persistence and Data Handling

Patient data are handled locally. The profile is serializable and is intended to persist on the device; nothing in the architecture transmits patient data to a remote service as a side effect of ordinary use. The single point at which data leave the device is the clinician handoff (Section 8.4), and even there the application composes a message in the user’s own mail client for the user to review and send, rather than transmitting autonomously. The persisted profile is protected at rest (Section 7.7). This local-first posture is a deliberate privacy decision (design rationale).

5. The Domain Configuration Schema

This section documents the configuration schema in detail, since it is the contract every disease must satisfy and the surface a content author works against. Table 1 summarizes the top-level fields.

5.1. Comorbidities

Each comorbidity record carries a label, a category, and a mechanism. The category is not an arbitrary grouping but an etiological or physiological driver — for example neurogenic/autonomic, endocrine/metabolic, autoimmune/inflammatory, structural/mechanical, genetic/inherited, post-infectious, or iatrogenic/drug-induced. The mechanism is a single clause stating the pathway that links the comorbidity to the primary disease. This structure was chosen so that the application teaches associations rather than merely listing them, and so that the comorbidity list is searchable by mechanism as well as by name (design rationale). The content methodology that produced these records is described in Section 6.

5.2. Numerical Metrics and Field Importance

Each metric record carries a key, a label, a numeric range and default, an importance level, and a purpose. Importance takes one of three values — required, recommended, or optional — which the interface renders respectively as a crucial (red) field, a useful (green) field, or a field that is hidden entirely. Purpose classifies the metric as bearing on treatment, dose, safety, or background. These two attributes drive the field-elimination behavior described in Section 8.2: optional fields are never shown, and once the patient has recorded at least one active symptom, background fields are removed so that only treatment-, dose-, and safety-relevant fields remain. Table 2 summarizes the importance and purpose vocabularies.

5.3. Symptoms and the Implications of Severity

Each symptom record carries a label, an activation threshold on a zero-to-ten severity scale, and a mechanism. A symptom is considered active when the patient’s recorded severity reaches its threshold.

This revision makes the downstream implications of severity explicit (design rationale). Recorded severities now drive three behaviors rather than being a passive label. First, they trigger the field-elimination logic of Section 8.2: once any symptom is active, background metrics are removed and the form narrows to what bears on treatment, dose, and safety. Second, they feed the treatment-ranking logic, which scores candidate treatments by how many of the patient’s active symptoms each addresses and by the severity at which those symptoms are recorded, so that a treatment targeting the patient’s most severe active symptoms ranks above one targeting only mild ones. Third, a small number of symptoms carry a high-severity escalation note: when such a symptom is recorded at or above a red-flag level, the symptom summary surfaces an explicit, non-directive prompt that the finding is one to raise promptly with a clinician or urgent-care service. The escalation prompt informs; it never diagnoses, never assigns urgency on the patient’s behalf, and never recommends a specific action.

5.4. Blood Tests

Each blood-test record carries a name, a clinical-purpose category, and a rationale. The category vocabulary mirrors the structure a laboratory-medicine consultant would use diagnostic, severity/prognostic, etiologic work-up, treatment-safety/monitoring, and baseline/screening. The rationale states, in one clause, what a clinically significant result indicates. The blood-tests page is positioned before the treatments page in the navigation, reflecting the clinical ordering in which work-up precedes treatment selection (design rationale). The elicitation prompt that produced these records is given in Section 6.2 and Appendix B.

5.5. Treatment Database and the Redesigned Record Format

Each treatment record carries a name, a category, the symptoms it targets, a mechanism, an evidence tier, a clinician note, cautions, a trial sample size, and flags indicating whether it is peer-reviewed and whether its trials have concluded. The sample size is mapped to a cohort-scale band, allowing the user to filter candidates by the scale of the evidence behind them. The evidence tier and the peer-review flag allow further filtering. These metadata exist so that the application can present not only what an intervention is but how strong and how mature the evidence behind it is — an honesty mechanism rather than a recommendation mechanism (design rationale).

This revision extends the treatment record with two fields and a redesigned presentation (design rationale). The first new field is an availability status — one of available, limited, investigational, or withdrawn — stating whether the intervention is currently obtainable in routine care, obtainable only under restricted conditions (for example, allocation, shortage, or specialist-only settings), available only within trials, or no longer in use. The second new field is a tried/ineffective status derived from the profile: a treatment the patient has recorded as already tried and either ineffective or not tolerated is marked as such and de-emphasized in ranking (Section 5.6). The redesigned record format presents these attributes as a single structured card: the name and category as a header; the targeted symptoms and mechanism as the body; and a row of status markers — evidence tier, cohort-scale band, peer-review and trials-concluded flags, availability, and tried status — as a footer. The card format replaces a flatter list presentation so that provenance, maturity, availability, and personal history are visible together rather than scattered, which is the point of the honesty mechanism: the user sees, in one place, how strong the evidence is, whether the intervention can actually be obtained, and whether they have already tried it without benefit.

We emphasize a deliberate limitation of the treatment schema: it contains no field for a patient-specific dose, and the application never computes one. Where dosing is discussed at all, it is reference-level and is gated behind the completion of required safety fields, as described in Section 7.3. This is a safety boundary, not an oversight.

5.6. Treatments Tried and Re-Ranking

A recurring reality of chronic and refractory illness is that a patient arrives at an encounter having already tried several interventions without benefit. Earlier versions of the Generator ranked treatments only against active symptoms and filter state, which meant an intervention the patient had already exhausted could still surface at the top of the list. This revision records, in the profile, the set of treatments the patient marks as already tried, together with an outcome flag distinguishing ineffective from not tolerated (design rationale).

The ranking logic was refactored accordingly. A shared, pure ranking routine — used both by the treatments page and by the self-validation harness — scores each candidate by symptom coverage and severity, then applies a demotion to any candidate the patient has marked as tried-and-ineffective, so that already-failed interventions sink beneath fresh candidates without being hidden entirely (a patient and clinician may still wish to see them, for example to reconsider a not-tolerated agent at a different formulation). A latent defect corrected in this refactor is that a populated database must never rank to an empty list: when cohort or peer-review filters exclude every candidate, the routine falls back to the full database and the treatments page shows an explicit fallback notice, so the user is never presented with an empty result that could be mistaken for “no treatments exist.”

6. Clinical Content and Methodology

6.1. Sourcing Approach

The clinical content bundled with the Generator was authored to be accurate at the level of drug classes and major associations, and explicitly not to be exhaustive. This distinction is central to an honest account of the system. For a given disease, the treatment collection lists representative interventions spanning the principal therapeutic classes rather than every agent in use; the comorbidity collection lists the major, and a selection of the rarer, associated conditions rather than a complete enumeration; and the blood-test collection lists the tests a clinician would commonly consider rather than every possible assay. No fabricated citations are attached to any record, because the schema contains no citation field and we declined to manufacture references to create an appearance of provenance the data do not have (design rationale).

This representative-not-exhaustive posture has a direct consequence for counts. A condition such as Long COVID, in a separate dedicated database maintained by the author, may carry on the order of several hundred catalogued treatments; the acute conditions bundled here carry single- to low-double-digit treatment counts because the space of distinct, evidence-supported acute interventions for those conditions is genuinely smaller. The application surfaces the bundled total explicitly on the treatments page — displaying, for the active disease, how many candidates are shown out of how many exist in the database — so that the user is never misled about the breadth of the underlying content. Section 10.1 reports these counts in full.

Several individual treatment entries are anchored to landmark trials, which we cite here to substantiate the content even though the running application does not display citations: the mortality benefit of dexamethasone in hypoxemic COVID-19 was established by the RECOVERY trial [23]; the outpatient benefit of nirmatrelvir-ritonavir was established by the EPIC-HR trial [24]; and the survival benefit of monoclonal-antibody therapy in Ebola virus disease was established by the PALM trial [25]. These citations illustrate that the bundled content is grounded in the clinical literature even where the schema does not carry the reference.

6.2. Structured Elicitation Prompts

Two of the content collections — comorbidities and blood tests — were populated with the assistance of structured elicitation prompts designed to produce comprehensive, categorized output. The prompts were written to force breadth (including rare and cross-system associations), to require categorization by a principled axis, and to require a mechanism or rationale for every entry. The comorbidity prompt instructs the model to act as a specialist in multi-system pathology and epidemiology and to map major, minor, rare, and emerging comorbidities, complications, predispositions, and overlapping syndromes, categorized by etiological or physiological driver, with the exact linking mechanism for each entry. The blood-test prompt instructs the model to act as a consultant in laboratory medicine and to enumerate diagnostic, severity/prognostic, etiologic, treatment-safety, and baseline tests, with the analyte, the meaning of a significant result, and the linking mechanism for each. Both prompts are reproduced verbatim in Appendix B.

The use of an AI assistant to draft this content is precisely why the application labels its content as AI-assisted and routes the user to a clinician. The elicitation prompts were designed to improve breadth and structure, not to confer authority; the literature on the reliability of such models [14,15,16] is the reason the resulting content is presented as input for verification rather than as established fact.

6.3. Per-Disease Content Summary

Table 3 summarizes the bundled content. Five diseases carry curated data across all collections; one, Long COVID, carries none because it is deliberately blocked and redirected. The counts below include the prevention measures added in this revision. The full per-disease listings appear in Appendix C.

6.4. Prevention Content

This revision adds a prevention measure collection to each curated configuration and a prevention page ahead of patient identifiers (design rationale). Each prevention record carries a label, a category — for example vaccination, exposure reduction, hygiene, environmental control, behavioral, or risk-factor modification — and a rationale stating, in one clause, how the measure reduces the likelihood or severity of the condition. The measures are general, literature-derived, public-health-level statements framed for discussion with a clinician; they are not a personalized prophylaxis plan and compute nothing patient-specific, consistent with the application’s information-not-advice posture. The prevention content was authored to the same representative-not-exhaustive standard as the rest of the bundled data, and the Long COVID block extends to prevention: the blocked configuration carries no prevention content, and the prevention page inherits the redirection notice.

7. Safety Architecture

The safety architecture is the part of the system we consider most important, and it is implemented entirely in the shared shell so that it applies uniformly to every disease, curated or templated. It comprises six mechanisms, described in turn, followed by a mapping to published non-device decision-support criteria.

7.1. Information, Not Advice

The foundational stance is that the application provides information, not medical advice. This is not merely a disclaimer line; it is a design constraint that shapes every output. The application never asserts a diagnosis, never recommends that a specific patient take a specific action, and never computes a personalized dose. Its content is framed throughout as AI-assisted, literature-derived material to be discussed with a licensed clinician, who decides what, if anything, is appropriate. This framing aligns with the central lesson of both the CDSS literature [3,7] and the generative-AI-in-medicine literature [14,16]: a tool that informs and defers is safer than one that decides.

7.2. The Pre-Treatment Acceptance Gate

Treatment content is the highest-risk material in the application, and it is withheld behind an explicit acceptance gate. On the treatments page, before any candidate is shown, the application presents a consolidated notice comprising the medical disclaimer, an explicit statement that the content is AI-generated and may contain errors, a safety paragraph instructing the user not to start, stop, or change any treatment on the basis of the application, and the full warranty, liability, and intellectual-property notices. The treatment candidates, the recovery-trajectory visualization, the dosage reference, and the clinician-handoff section are all suppressed until the user toggles an explicit acknowledgment. Withdrawing the acknowledgment re-hides them. This mirrors a disclaimer-acceptance pattern the author has used in prior work and ensures that no user reaches treatment content without having been shown, and having accepted, the governing notices (design rationale).

7.3. The Dosage Gate and the No-Personalized-Dose Boundary

The application includes a dosage reference, but it is constrained in two ways that together prevent it from becoming a prescribing tool. First, it is gated: before any dosage reference is shown, the user must have completed the required safety fields — specifically, known allergies and adverse reactions, and current medications and treatments tried. If either is missing, the application lists the missing fields and withholds the reference until they are supplied. Second, and more fundamentally, the reference never computes or displays a patient-specific dose. It presents the selected treatment’s safety cautions together with an explicit statement that dosing must be determined by a licensed clinician using the patient’s full history, and that the application does not provide patient-specific doses. This boundary is deliberate and is, in our view, the single most important safety decision in the system: a consumer application that computed personalized drug doses from user-entered data would cross from information into prescription, with attendant risk of harm if the computation were wrong [14,16].

7.4. The Deliberately Blocked Condition

The application blocks one condition — Long COVID, together with its synonyms such as post-acute sequelae of SARS-CoV-2 and post-COVID syndrome — and redirects the user to a dedicated application maintained separately for that condition. The block is implemented at the disease-resolution layer (Section 4.4): any entered name matching the synonym set routes the entire detail pane to a redirection notice, and the corresponding configuration carries no content, including no prevention content. This mechanism serves two purposes. Practically, it directs users to a more complete resource for that specific condition. Architecturally, it demonstrates that the Generator can enforce scope boundaries — that a disease can be recognized and deliberately declined, not merely covered or uncovered (design rationale).

7.5. Disclaimers, Warranties, Liability, and Intellectual Property

The application carries four categories of notice, drawn from the author’s established language for prior work. The medical disclaimer states that the recommendations come from a database of treatments drawn from published medical research, that they are AI-generated and are not medical advice, and that they should be used only as a starting point for a conversation with a licensed physician. The warranty disclaimer states that use is at the user’s sole risk and that the application is provided as is and as available, with all warranties disclaimed. The liability limitation states that the author shall not be liable for indirect, incidental, special, or consequential damages arising from use. The intellectual-property notice asserts the author’s copyright in the database, content, and design. These notices appear on the welcome page in summary and in full on the treatments page within the acceptance gate.

7.6. Mapping to Non-Device Decision-Support Criteria

The FDA’s criteria for clinical decision support software that is excluded from device regulation emphasize, among other things, that the software inform rather than direct decisions, that it not provide a specific patient-directed output that replaces professional judgment, and that the basis for its information be transparent and independently reviewable [9,10]. Table 4 maps the Generator’s features to these themes. We present this mapping as a statement of design intent consistent with the published criteria, not as an assertion of regulatory status, which is a determination reserved to the relevant authority.

7.7. Local Data Protection

This revision strengthens the handling of patient data at rest (design rationale). The serialized profile — which may contain identifiers, symptom severities, medications, allergies, and treatments tried — is stored in protected form on the device rather than as clear text, so that the working record is not casually readable outside the application. The clinician handoff, which is the single point at which data leave the device, was tightened so that the action remains disabled until the required recipient fields (clinician name, telephone number, and a validated email address) are present, and so that the message is always composed in the user’s own mail client for explicit review before sending. No patient data are transmitted autonomously, and no analytics or telemetry are collected. We are candid about the boundary of this claim in Section 10.3: the profile is protected against casual access, but the application is a consumer tool on a general-purpose device and does not claim the assurances of a regulated system or a formally audited cryptographic implementation.

8. User Interaction and Workflow

8.1. Navigation and Pages

A typical session proceeds through the pages in the order the configuration lists them: a welcome page introducing the condition; a prevention page describing how the condition may be avoided or its onset reduced; a run-and-patient page for identifiers; a clinical-metrics page; a comorbidities page; a symptom-severity page; a symptom summary; a blood-tests page; a treatment-candidates page; a follow-up-notes page; and a questions-for-your-doctor page. The prevention page is new in this revision and is deliberately placed ahead of patient identifiers, so that avoidance and risk-reduction information is encountered before any personal data are entered. The remaining ordering reflects a clinical workflow in which background and history precede symptom assessment, which precedes work-up, which precedes consideration of treatment. The blood-tests page deliberately precedes treatments, as work-up precedes therapy selection.

8.2. Field Importance and Progressive Elimination

The metrics interface renders each field according to its importance: crucial fields are marked in red, useful fields in green, and unnecessary fields are not shown at all. Once the patient records at least one active symptom, the interface removes background fields, leaving only those relevant to treatment, dose, or safety. The effect is that the form a user sees becomes shorter and more focused as the assessment progresses, concentrating attention on what matters for the decisions ahead. This behavior operationalizes the field-importance metadata described in Section 5.2 and reflects a usability principle drawn from the decision-support literature: surfacing the actionable and suppressing the irrelevant improves both efficiency and appropriate use [4,17].

8.3. Search

Comorbidities, symptoms, blood tests, and treatments are searchable. The search supports three modes: matching within a single named field, matching across all fields, and free-text matching against the concatenation of fields. Because each content record exposes its searchable fields — including mechanism and rationale text — the user can locate, for example, every comorbidity whose linking mechanism involves a particular pathway, not merely those whose names contain a search term. This makes the mechanism and rationale content navigable, not merely decorative.

8.4. Clinician Handoff

The application can assemble information for the patient’s clinician. On the treatments page, behind the acceptance gate, the user may elect to send a summary of their record to their physician. Doing so requires the physician’s name, telephone number, and a validated email address; the application lists any missing required field and disables the action until all are present. When the action is taken, the application composes a message in the user’s own mail client, pre-filled with the summary — including the treatments the patient has tried and their outcomes — and with a request that the receiving clinician confirm receipt by replying with their medical identifier; the user reviews and sends the message themselves. The application records the clinician’s medical identifier when supplied and displays a confirmation indicator. No patient data are transmitted autonomously; the handoff is user-initiated and user-reviewed throughout (design rationale).

We note candidly that the receiving-clinician confirmation is modeled within a single patient-side application rather than implemented as a separate authenticated clinician portal. The medical identifier is requested in the composed message and recorded when entered; a fuller implementation would involve a distinct clinician-facing receipt flow. Section 12 lists this as future work.

8.5. The Treatment Card and Its Status Markers

The redesigned treatment presentation (Section 5.5) renders each candidate as a structured card. The header shows the treatment name and therapeutic class. The body shows the targeted symptoms and the mechanism of action. The footer shows a row of status markers: the evidence tier (high, moderate, low), the cohort-scale band derived from the trial sample size, the peer-review and trials-concluded flags, the availability status, and — when the patient has recorded it — the tried/ineffective marker. The recovery-trajectory visualization continues to encode trial maturity through line styling (solid for active peer-reviewed trials, dashed for concluded ones, dotted for non-peer-reviewed), so that nothing renders as an improvement line that the underlying flags do not support. The purpose of the card is honesty at a glance: strength of evidence, obtainability, and personal history are visible together.

8.6. Recording Treatments Tried

From the treatments page, the user may mark a candidate as already tried and flag the outcome as ineffective or not tolerated. The marked treatment is retained in the profile, and its status is reflected on the card and in the handoff summary. Marking a treatment tried-and-ineffective demotes it in the ranking (Section 5.6) rather than removing it, so the patient and clinician retain visibility of the full history. This directly addresses the common situation in which a patient has exhausted several options and needs the tool to foreground what remains rather than repeat what has already failed.

8.7. Visual and Animation Layer

For non-psychological conditions, the welcome page presents a small, looping illustration of the disease’s biochemical structure — a coronavirus virion, an influenza virion, a filamentous filovirus, a tick, or a generic molecule, selected by the configuration’s icon kind. The illustrations are rendered as vector graphics animated by the framework, not as embedded video. The application also contains an optional facility to play a bundled looping video and an optional background audio track when those assets are present in the application bundle, falling back to the vector animation when they are absent. We are explicit that the application does not generate video or music; it plays assets the developer supplies, and the vector animation is the default. This visual layer is engagement-oriented and carries no clinical content (design rationale).

9. Implementation

9.1. Single-File SwiftUI Architecture

The application is implemented in SwiftUI as a single self-contained source file. This packaging choice reflects the author’s working method, in which the entire application is reviewed and rebuilt as a unit, and it simplifies distribution and inspection. The declarative nature of SwiftUI [19] is essential to the architecture: views are functions of the observable state, so the reactive consistency required by the design (Section 3.2) is provided by the framework rather than by hand-written update logic.

9.2. View Decomposition

A practical constraint shaped the implementation. SwiftUI’s type inference can fail to compile view bodies that are too large or too deeply nested, manifesting as compiler timeouts rather than as ordinary errors. The implementation therefore decomposes complex pages into many small subviews and computed properties, each individually simple enough to type-check quickly. The redesigned treatment card and the new prevention page were both built as small, composable subviews for this reason. This decomposition is invisible to the user but is a recurring consideration in maintaining the single-file structure (design rationale).

9.3. Cross-Platform Operation

The application targets both macOS and iOS from one codebase. Platform-specific concerns — for example, the construction of a looping video view, which uses different underlying view classes on the two platforms — are isolated behind conditional compilation, so that the shared code path remains identical. The navigation structure adapts to the platform’s conventions through the framework’s adaptive containers.

9.4. Asset Pipeline

The application icon is supplied through the platform asset catalog rather than through code; the project includes a generated icon set spanning the required macOS and iOS sizes, produced from a single high-resolution source image flattened to the opaque format the platforms require. Optional disease-specific video and audio assets, when present, are loaded by name from the application bundle. The separation of assets from code keeps the source file focused on logic and content structure.

9.5. Ranking as a Shared, Testable Routine

The treatment-ranking logic was extracted into a pure routine shared by the treatments page and the self-validation harness, so that the behavior the user sees and the behavior the harness checks are the same code. The routine takes the active symptoms, the filter state, and the set of treatments tried, and returns an ordered candidate list that never collapses to empty for a populated database. Testing the ranking against a clean default state rather than the transient UI filter state removed a false failure in which a restrictive filter had made the candidate list appear empty.

10. Evaluation and Discussion

10.1. Coverage Analysis

We report coverage transparently. The Generator can present any disease name a user enters, so the count of presentable diseases is open-ended. The count of diseases with curated content is five — COVID-19 (acute), orthostatic hypotension, influenza, Ebola virus disease, and Long Lyme (post-treatment Lyme disease syndrome). One condition, Long COVID, is deliberately blocked and redirected. Every other name resolves to a navigable but empty template. Table 3 reported the per-collection counts for the curated diseases; in aggregate, the bundled content comprises 74 comorbidity records, 38 symptom records, 28 treatment records, 48 blood-test records, and 30 prevention records across the five curated diseases.

Set against the scale argument of Section 1.2 — thousands of rare diseases alone [1,2], and far more conditions overall — this coverage is, by design, a small fraction of the possible space. The point of the architecture is not that five diseases are covered but that the marginal cost of the sixth, or the sixtieth, is the authoring of a configuration rather than the construction of an application. The empty-template behavior means that the application is already functional, not broken, for the conditions it has not yet been taught.

10.2. Strengths

The principal strengths of the design are three. First, the decoupling of content from software means the safety scaffolding is implemented once and cannot be inconsistently applied across diseases — a direct response to the inconsistency that afflicts per-disease portfolios. Second, the explicit, layered safety posture — acceptance gating, the no-personalized-dose boundary, provenance labeling, honest availability and tried-status reporting, at-rest data protection, and scope blocking — is conservative in the direction the literature recommends [9,14,16]. Third, the transparency mechanisms — visible mechanisms and rationales, visible evidence tiers and cohort scales, visible availability, visible content counts, and explicit AI-assisted labeling — position the tool as an honest organizer of information rather than an oracle.

10.3. Limitations

The limitations are equally real and we state them plainly. The bundled clinical content, including the new prevention measures, is representative, not exhaustive, and carries no per-record citations; a clinician or researcher seeking comprehensive, sourced content would find the present data a starting point rather than a reference. The content was drafted with AI assistance, and although it was authored to be accurate at the level of drug classes and major associations, it has not undergone formal expert review or external validation, and the generative-AI literature gives ample reason to verify rather than trust such content [14,15,16]. The availability status reflects a point-in-time authoring judgment and can go stale as approvals, shortages, and withdrawals change. The at-rest protection guards against casual access on a general-purpose device but is not a formally audited cryptographic implementation and makes no regulated-system assurances. The application has not been evaluated for clinical effectiveness, usability, or patient outcomes; no user study has been conducted. The clinician-handoff confirmation is modeled rather than fully implemented as an authenticated flow. And the decorative visual layer, while engagement-oriented, contributes nothing clinical and could be misread as implying a sophistication the content does not claim.

10.4. Threats to Validity

Because this report describes a single system authored by its proponent, the most serious threat to validity is the absence of independent evaluation. The design arguments are reasoned and are grounded where possible in external literature, but the claims about safety and usefulness are, at this stage, design rationale rather than empirical findings. A second threat is content validity: the representative content — now including prevention measures — could contain errors that we, lacking formal review, have not detected. A third is construct validity in the coverage claim: “diseases the application can handle” is open-ended only in the sense that any name produces a navigable template, which is a weaker claim than “diseases the application covers.” We have been careful to distinguish these throughout.

10.5. Relationship to the Decision-Support Literature

The Generator is consistent with, rather than a test of, the CDSS literature. That literature finds decision support effective under conditions of workflow fit, actionable output, and transparency [4,5,6,7]. The Generator is patient-facing and non-advisory, so its outputs are informational rather than directive, but it adopts the transparency and actionability principles directly: it surfaces relevant, organized information and suppresses the irrelevant. Whether this translates into improved appointment preparation or shared decision-making is an empirical question this report does not answer and that Section 12 identifies as future work.

11. Ethical, Legal, and Regulatory Considerations

Three considerations deserve explicit treatment. First, patient safety: the system’s conservative posture — informing rather than advising, never computing doses, gating treatment content, reporting availability and tried status honestly, protecting data at rest, and disclosing AI provenance — is an ethical commitment as much as a design choice, motivated by the documented unreliability of generative models in medicine [14,16] and by the principle that a tool used by non-experts must fail safe. International guidance on the ethics and governance of artificial intelligence for health emphasizes transparency, human oversight, and accountability [21], and the Generator’s provenance labeling and clinician-deferral are aligned with that emphasis.

Second, regulatory positioning: the application is designed to be consistent with the criteria distinguishing non-device clinical decision support [9,10], chiefly by informing rather than directing and by keeping its basis transparent and reviewable. This is a statement of design intent; any operative regulatory determination rests with the relevant authority and would depend on the application’s specific claims and use.

Third, intellectual property and content provenance: the application asserts the author’s copyright in its database and design, and it does not attach citations to clinical records it cannot source. We regard the decision not to fabricate citations as an ethical one. The decorative iconography, if drawn from third-party artwork, would require appropriate rights before distribution — a matter the developer must resolve outside the software itself.

12. Future Work

Several extensions follow naturally from the present design (design rationale):

• Sourced content: extend the schema with a citation field and attach verifiable references to treatment, comorbidity, prevention, and laboratory records, enabling a reference-grade rather than representative dataset.
• Bulk content ingestion: provide an import path so that a curated external database — for instance, the author’s several-hundred-entry Long COVID treatment dataset — can populate a disease configuration directly.
• Availability freshness: attach a dated review to each availability status and prompt re-review, so the obtainability of an intervention does not silently go stale.
• Audited data protection: replace the current at-rest protection with a formally audited cryptographic implementation and document a threat model.
• Expert validation: subject the bundled content, including prevention measures, to formal clinical review and report inter-reviewer agreement, converting design rationale into evidence.
• Authenticated clinician handoff: replace the modeled receipt-confirmation with a distinct, authenticated clinician-facing flow.
• Usability and outcomes evaluation: conduct user studies measuring appointment preparation, comprehension, and the appropriateness of clinician deferral.
• Retrieval-grounded content authoring: where AI assistance is used, ground generation in retrieved, verified literature to reduce hallucination, consistent with the mitigation strategies emerging in the literature [15].

13. Conclusions

The number of human diseases is far larger than any per-disease portfolio of applications can address; even the rare-disease subset numbers in the thousands [1,2]. This report has argued that a configuration-driven generator is a more appropriate response to that scale than a portfolio, and it has described such a generator in detail. By making the disease a free-text parameter that resolves to curated content when recognized and to a navigable template otherwise, the Medical App Generator decouples the problem of authoring clinical content from the problems of building software and engineering safety, solving the latter two once in a shared shell.

This revision deepens the tool’s honesty and its safety posture rather than its scope: treatments now carry an availability status and a tried/ineffective history and are presented in a single structured card; recorded symptom severities carry explicit implications for what the form shows, how treatments rank, and when an escalation prompt appears; the local profile is protected at rest; and a prevention page, placed ahead of patient identifiers, describes how the selected condition may be avoided. The system’s most consequential design decisions remain its safety decisions: to inform rather than advise, to gate treatment content behind explicit acceptance, to refuse to compute a patient-specific dose, to disclose AI provenance, to report availability and personal history honestly, and to enforce a scope boundary by deliberately blocking a condition. These choices are conservative in the direction the clinical-decision-support and generative-AI literatures recommend [9,14,16]. We have been careful to distinguish what is grounded in that literature from what is, at this stage, design rationale awaiting evaluation. The honest conclusion is that the architecture is a defensible pattern for patient information tools and that its value now depends on the work that remains: sourcing the content, validating it, and evaluating the tool in use.