Diagnosis-Linked Patient Education: The Right Module, Not a Portal Search

Most patient portals treat education as a library. The patient is handed a diagnosis and left to find the matching article — if they look at all. The content usually exists, but the patient has to discover it, and the burden of relevance falls on the person least equipped to carry it. Diagnosis-linked education flips that: the diagnosis itself decides which module the patient sees.

The problem with a generic library

A generic education library fails quietly. The article is accurate and well-written, but:

• The patient has to go looking. Self-directed search assumes the patient knows what to search for and is motivated to do it at exactly the moment they are most overwhelmed.
• Breadth becomes noise. A library that covers everything gives a patient with one condition a hundred things that are not theirs. Relevance drops as breadth rises, unless something narrows it for them.
• Nothing ties it to the encounter. Education that is not connected to what just happened in the visit reads as background material, not as instructions the patient recognizes as their own.

The content is not the problem. The routing is.

What "diagnosis-linked" means

Diagnosis-linked patient education means the diagnosis a clinician has already recorded selects the education the patient receives. The clinician makes the clinical decision; the mapping delivers the matching module. The patient's first click is already the right one — no search, no library, no guessing.

This keeps the education specific to the condition instead of dumping the patient into a portal to fend for themselves. It is the same principle that makes post-discharge education stick: material the patient recognizes as theirs is material they actually engage with.

How the mapping works, conceptually

The mechanism is a lookup, not intelligence. A diagnosis — often expressed as an ICD-10 code already present in the encounter — maps to the module that covers it. The connection can be made a few ways depending on the workflow:

• Deep link. A per-module URL that a diagnosis maps to. The EHR, portal, or after-visit workflow already knows the diagnosis; it resolves that to the module link and hands it to the patient. No integration beyond building the URL.
• Code-to-module mapping. An ICD-10 code resolves to the corresponding module through a maintained mapping table. When the encounter closes with that code, the matching education is what the patient gets.
• API request. For teams that want it programmatic, a request carrying the diagnosis returns the right module reference, which the platform then embeds or links.

In every case, the platform makes no clinical determination. It receives a diagnosis a clinician assigned and returns the education mapped to it. The apps educate against that diagnosis — they do not diagnose, and they collect no PHI in standard use, so the mapping can carry a code without pulling patient data into the education layer.

Why the mapping has to be maintained by a clinician

A code-to-module map is only as good as the modules behind it and the judgment that built it. That is why the mapping matters as much as the mechanism:

• Modules have to be physician-authored and kept current against national guidelines, or the map routes patients to stale content faster.
• Codes have to map to the module a clinician would actually choose — the routing decision is a clinical one made once, in advance, so it does not fall to the patient at click time.

The library behind the mapping is 146 physician-authored, interactive modules, which is what makes the diagnosis-to-module link worth building — the destination is depth, not a stub.

Where it fits

Diagnosis-linked delivery is the routing layer under most of the platform. It is what makes care-gap closure and medication adherence land on the right content, and it is how digital health and telehealth teams wire relevant education into an existing product without building a library.

If you want to see how a diagnosis in your workflow resolves to a real module, the fastest path is to test it against your top conditions. Request a guided review and we will walk the mapping against your codes.