Your Rare Disease Overview Page is often the Front Door

A rare disease page is often the front door. Someone searches a condition they have just heard for the first time, they land on a few thousand words written by a medical editor or genetic counselor, and they make a fast decision about whether this source can be trusted and perhaps more importantly, whether it offers next steps. Everything the organization publishes downstream, the advocacy updates, the community events, the research programs, depends on that first page earning the reader's confidence.

At KISHO, we treat the disease report as a live node in a graph, not a static document. Here is how that works and what it takes to build.

Step one: understand what the report actually is

A well-curated disease report is not just prose. It is an information artifact with structure. It names a disease, usually by a preferred term and a handful of synonyms. It references genes, proteins, and inheritance patterns. It describes clinical features. It points the reader toward next steps, whether that is finding a specialist, joining a patient organization, applying for assistance, or evaluating a clinical trial.

Every one of those elements has a counterpart somewhere else in the rare disease data universe. The gene has an HGNC symbol. The clinical features map to HPO terms. The specialists are in provider directories. The patient organizations publish their own content. The assistance programs are administered by foundations and pharmaceutical companies. The trials are on ClinicalTrials.gov. The registry is usually its own site.

I spent seven years as the web project lead at a national rare disease nonprofit. A lot of that time was spent maintaining those connections by hand, or watching curators maintain them by hand. The report was the front door, and everything else the community needed lived in a different system.

The first step in solving this is understanding, structurally, what the report is supposed to connect to. Not treating it as body copy with a sidebar. Treating it as a document that has semantic obligations to the rest of the rare disease data universe.

Step two: use analytics to understand what the audience actually came for

The second step is less obvious but it is the one that shaped everything else. Before deciding what to connect a report to, you have to know what the reader was trying to do when they arrived.

Years of analytics on a high-traffic rare disease site taught me that the audience does not arrive with one goal. They arrive with several, and the distribution is specific to the disease. For some conditions, the top intent is "find a doctor who has seen this before." For others, it is "find a clinical trial I might qualify for." For others, it is "find a community of other families." The analytics show you this directly: which internal links get clicked, which sections get read to the end, which searches lead to which exits, which pages convert to a newsletter signup versus a donation versus a trial inquiry.

KISHO uses this kind of signal to decide what to surface around a disease report, not just what content exists. A report for a condition where readers consistently search for assistance programs should surface assistance prominently. A report for a condition where readers consistently search for trials should surface trials. The report stays the same. The connective tissue around it adapts to what the audience is coming for.

Step three: map the report to an authoritative ontology

The third step is the one that makes the first two scalable. Every authoritative source in rare disease names diseases differently. ClinicalTrials.gov uses a free text condition field. PubMed uses MeSH terms. FDA uses product labels. Orphanet has its own IDs. OMIM has its own IDs. NIH RePORTER categorizes differently. A registry might use a clinical synonym that appears nowhere else. A patient assistance program might be named after a drug rather than a disease.

If you want a disease report to be connected to all of that automatically, you need a shared identifier. That identifier is MONDO, the Mondo Disease Ontology. MONDO is an open, community-maintained ontology that unifies disease terminology across the major sources. Orphanet, OMIM, DOID, MeSH, ICD, and several others all cross-map to MONDO. Once a report is mapped to a MONDO ID, the connections to every other source become automatic.

KISHO maps every disease in our system to MONDO as the backbone. A disease report is then cross-linked, by that ID, to the relevant ClinicalTrials.gov entries, PubMed publications, NIH grants, FDA designations, patient organizations, and policy updates. The curation stays where it belongs, with medical editors writing the report. The connective tissue becomes a data engineering problem, which is the right place for it.

What that changes

The outcome is that a disease report stops being a document that someone has to remember to update and starts being a live node in a graph that updates as the field does. A new trial opens, it appears on the relevant reports. A new publication lands in PubMed, it surfaces on the reports where it matters. Congress introduces legislation affecting a therapy, the affected disease reports reflect it. The curator's job stops being link maintenance and starts being the work that requires clinical judgment.

This is the work KISHO was built to do. It is also the work I spent seven years inside a rare disease nonprofit learning how to do. You cannot arrive at it from outside. You have to have watched the curators do the manual work, seen the links go stale, and understood why.

If your organization runs a disease information product and you have felt this problem, I'd like to talk.