University Hospitals' MyChart comes back online, still patchy after 16 days

University Hospitals (UH), a 21-hospital system based in Cleveland, Ohio, detected unusual activity on its servers on Oct. 22 and disconnected systems from the internet as a precaution, according to Cleveland 19's reporting. That took the MyChart patient portal offline for more than two weeks, cutting patients off from test results, messaging and appointment scheduling. UH restored MyChart access on Nov. 7, calling it "the sign that UH has recovered" — while cautioning that some features may not be fully functioning and new test results may show a delay as data is reconciled. A proposed class-action lawsuit, filed Oct. 28 in the Northern District of Ohio per Becker's Hospital Review, alleges UH failed to protect patient data and that sensitive information was stolen; UH has not publicly confirmed ransomware or the scope of any data taken. For a team weighing how to build the kind of patient-facing software that degrades gracefully instead of going dark for 16 days, that's a case worth studying before YuSMP Group's web development team starts the next portal build.

Why "back online" and "fully functioning" aren't the same thing

The gap between those two states is the real story. UH didn't say MyChart failed outright and then came back whole — it said the portal is accessible again but certain features and fresh test-result syncing are still catching up. That's consistent with a system where the patient portal, scheduling, lab-result pipelines and messaging aren't cleanly separated services that can be validated and brought back one at a time. If they were, UH could plausibly have restored read-only test-result viewing or appointment lookups days before full write access to messaging, rather than holding the whole portal dark until everything cleared security review together.

The 16-day number is an architecture signal, not just a security one

Security incident response — forensics, containment, credential rotation — explains part of a multi-week outage. But once systems are confirmed clean, how fast a hospital can bring patient-facing functionality back online depends on how that functionality was built. A monolithic portal that shares a database, an auth layer and a deploy pipeline across every feature has to pass the same all-clear bar before any of it ships back to patients. A portal built as independently deployable services — results viewing, scheduling, secure messaging, billing — can restore and re-verify each piece on its own timeline, instead of patients waiting on the slowest-to-clear component to unblock all of them.

What this means for the next incident, not just this one

Comparitech's Q3 data cited in recent coverage put healthcare ransomware attacks at an average of 3.33 per day industry-wide — UH is one case in a pattern, not an outlier. The practical takeaway for any clinic or health system commissioning patient-facing software isn't "add more security," it's "ask how the system comes back" before it goes down. A vendor or build partner should be able to describe which features fail independently of which others, and what a partial restoration actually looks like for a patient mid-incident. Most RFPs never ask that question until after an outage forces it.