If you have used a patient portal in the US in the last ten years, you have almost certainly used MyChart. Epic’s patient-facing portal underlies the digital experience of most major health systems, and the experience has changed remarkably little since it became standard practice in the early 2010s. The screens feel familiar in a way that is not a compliment.
This is not a problem of design talent. Epic and Epic’s customers have plenty of designers, and they have made measurable improvements over the years. The MyChart problem is structural — a feature of how the platform fits into the organizations that deploy it. Understanding the structure is the only way to plan around it.
Why MyChart looks the way it does
Three structural forces have kept MyChart frozen in the visual and interaction language of the early 2010s.
The patient-facing portal sits inside an EMR. MyChart is not a standalone consumer product. It is the patient-facing surface of Epic, an EMR built for clinicians, optimized for clinical workflows, and integrated with the deep architecture of the medical record. The portal has to be data-faithful to the EMR. The patient surface inherits the EMR’s underlying object model — encounters, results, orders, medications, problem lists — whether or not those are the units a patient thinks in.
The health system is the customer, not the patient. Epic sells MyChart to health systems. Health systems configure it. The patient is the end user but not the buyer. The features that get prioritized are the features health systems request, which are usually clinical, operational, or compliance features — not consumer-grade experience improvements. The consumer experience improves slowly because the buyer is not asking for it urgently.
Health systems customize MyChart, often badly. Most health systems customize their MyChart deployment heavily — branded headers, custom labels, additional modules, configured workflows. Many of these customizations make the experience worse, not better. The base product is consistent across deployments; the customizations vary in quality, and the worst customizations are usually the ones the patient encounters first.
The result is a patient portal that is technically sophisticated, deeply integrated, and reliably present at every major health system — but that looks and feels like a 2012 enterprise application, because that is structurally what it is.
What patients actually try to do with the portal
When patients open the portal, they are almost always doing one of four things:
- Looking at a recent lab or imaging result — and trying to understand whether it is normal.
- Sending a message to their care team — usually a question about a symptom, a medication, or an appointment.
- Scheduling, rescheduling, or canceling an appointment.
- Looking at a bill or a balance.
Almost every patient session boils down to one of those four tasks. The portal that gets used well is the one where those four tasks are one tap away, clearly labeled, and quick to complete. Every other surface — the problem list, the medication list, the immunization history, the released-letter inbox — is occasionally useful but not what patients are usually there for.
The MyChart pattern of giving equal visual weight to thirty different modules on the home screen is the problem. Each module makes sense in isolation. Together they obscure the four tasks the patient is actually trying to do.
What health systems can actually do about it
There is no universe in which a US health system rewrites MyChart from scratch. The integration depth, the regulatory load, and the cost of switching make the base platform essentially fixed. The realistic options for a health system that wants a better patient portal experience are narrower than the marketing decks suggest.
Option 1: Aggressive configuration of the base product. MyChart has more configuration surface than most deployments use. The labels, the module order, the home screen layout, the message routing, the appointment flow — all configurable. Most health systems take the defaults. A configuration-first redesign — without writing custom code — can move the portal experience forward measurably. The constraint is design discipline, not technology.
Option 2: A wrapper or companion app. Some larger health systems have built a custom mobile app that uses Epic’s APIs (USCDI, FHIR, MyChart Bedside, etc.) to surface the four primary tasks in a much simpler interface, with the full MyChart experience available as a fallback for less common actions. The wrapper is consumer-grade; MyChart is the system of record behind it. This pattern works but it is operationally expensive — two surfaces to maintain, two release cycles, two design systems.
Option 3: Tight design system control over the configuration layer. This is the pattern we recommend in most engagements. A healthcare design system, owned by the health system, that defines how the portal should be configured — typography, color, terminology, message templates, appointment flow language, balance display, lab result formatting. Apply the design system to the MyChart deployment. The base product is unchanged; the configured surface is dramatically better. The investment is in the design system, not in a new portal.
Option 4: Wait for Epic. Epic has been investing in modernization. The portal experience does improve year over year. A health system that is willing to wait, take Epic’s updates, and configure conservatively will end up with a better portal in three to five years than they have today, at very low cost. This is a defensible strategy if patient experience is not currently a strategic priority.
The option that most health systems pick implicitly — heavy customization of MyChart without a design system, accreted over many years — is the worst of the four. It produces an inconsistent surface, a maintenance burden, and a patient experience that is worse than the base Epic deployment.
What good looks like
A good patient portal experience — within the structural constraints of MyChart — looks something like this:
- The home screen has three to five large, prominent surfaces matching the four tasks patients actually do. Everything else is one level deeper.
- Lab results are presented with plain-language summaries on top of the clinical detail. “Most of your values are in the normal range. One is slightly elevated; your care team will follow up.” The clinical record is below it.
- Messaging is fast, threaded, and clearly routed. The patient knows who they are writing to and when to expect a response.
- Appointment scheduling presents three to five upcoming options, not a calendar. The patient picks one. The interaction ends.
- Billing surfaces show a single balance, a single action, and a one-line explanation. The full detail is one tap away.
- Terminology is patient-readable everywhere. “Visit summary” not “AVS.” “Vaccine record” not “Immunization history.” “Provider” not “rendering provider.”
- Visual language is recognizable as the health system’s brand, but conservative and institutional — not consumer-fashionable.
None of that requires a custom portal. All of it can be achieved with disciplined configuration, a healthcare design system, and the operational commitment to keep the surface clean as Epic releases new modules.
The shorter version
MyChart looks like 2012 because it was built inside an EMR, sold to health systems rather than patients, and customized by every deployment that ships it. The structure will not change soon, and rewriting it from scratch is not realistic for any US health system.
The realistic path is design system discipline applied to the configuration layer — a healthcare design system that defines how MyChart should be configured, applied consistently across the deployment, and updated as Epic ships new capabilities. The base portal stays. The configured surface gets dramatically better. The patient experience moves forward without a platform replacement.
The health systems that figure this out over the next five years will have meaningfully better patient portals than the ones that do not. The platform is not the constraint. The design system is.