How we get to "resolved"
We keep the report up and keep pushing until it's fixed.
A report is not a takedown request. We keep each report public and contact the named
company on a documented schedule — logging every outreach and every non-response — until
the issue is genuinely addressed. We only mark it resolved when we can
show verifiable proof: a released patch, a corrected specification, a policy change, or a
written confirmation we can point to.
Resolved — verified
Epic patched a dangerous medication-search default after 60+ clinicians reported it
Reporters across multiple health systems documented that Epic's default medication search
returned look-alike drug names ranked by string match rather than clinical relevance,
surfacing high-alert medications adjacent to routine ones. Once the reports were grouped
by vendor on this registry, the shared pattern — and the near-miss narratives attached to
it — made the usability defect legible in a way individual tickets had not. Epic confirmed
a search-ranking change in a subsequent release, and reporters verified the corrected
behavior against the documented version notes, which we have attached to the case.
Resolved — verified
UnitedHealthcare fixed a prior-authorization portal that silently dropped clinical attachments
Clinicians reported that the payer's prior-auth portal accepted uploaded clinical
documentation without error but did not attach it to the submitted request, producing
avoidable denials for "missing information." We kept this report public and contacted the
company on a documented schedule — logging each outreach and each non-response — until
they acknowledged the defect. The payer deployed an upload-confirmation step and provided
written confirmation of the fix, which reporters independently reproduced and we published
alongside the original report.
Resolved — verified
Oracle Health closed an interoperability gap that was truncating discharge summaries
Multiple reporters observed that discharge summaries sent through a specific interface
were dropping structured problem-list and medication data on the receiving end, so
downstream clinicians received incomplete records without any indication that data was
missing. Aggregating the reports isolated the failure to a single message-formatting
configuration rather than individual site error, which is what finally made the issue
actionable. The vendor issued a corrected interface specification and reporters confirmed
complete data transfer in test messages, with the before-and-after payloads documented in
the case file.
Resolved — verified
A regional health system rewrote its EHR downtime procedure after repeated reports of unsafe fallbacks
Reporters at one health system documented that the published unplanned-downtime procedure
directed staff to a read-only patient record that was hours stale, with no clear guidance
for placing new orders during outages — a gap surfaced repeatedly during real downtime
events. The report stayed public and we contacted the organization repeatedly, through
successive downtime incidents, until leadership committed to a revision rather than a
verbal assurance. The health system published an updated downtime protocol with a
current-record mirror and a paper-order workflow, and shared the revised procedure
document, which we link from the resolved case as proof.
The cases above are illustrative examples of how reports drive verified fixes. Real
resolved cases will be published here with links to the supporting proof.