Find the right patient
Names repeat. MRNs change across systems. Search needed enough identifiers to disambiguate a record before anyone opened it.
Risk: wrong-patient access01 / The problem
Changing the EHR doesn’t make the old record disappear.
When a health system moves to a modern EHR, years of records remain in systems that are expensive to maintain but risky to switch off. Muspell turns those disconnected archives into one FHIR-native access layer.
Fragmented input
30+ EHRs
Cerner, MEDITECH, eCW and more
Normalize + govern
Muspell
FHIR-native archive
Contextual access
One record
Inside the active workflow
Public context, checked Aug 2026
314e describes Muspell as cloud-based and FHIR-native, with support for 30+ EHRs and more than 1 PB of archived customer data. These are company-reported product metrics—not impact attributed to our design work.
View product source ↗The design challengeHow might we make scattered records feel unified without hiding where the data came from—or who is allowed to see it?
02 / Framing the work
The archive had three jobs. Each came with a different kind of risk.
Early conversations with product, engineering, HIM, and hospital IT moved us away from a generic “health dashboard.” We framed the experience around three high-stakes jobs.
Trust what you’re reading
A free-text allergy from an older system does not carry the same certainty as a coded entry. Source and provenance had to travel with the data.
Risk: false clinical certaintyRelease it defensibly
HIM teams needed selection, export, disclosure history, and auditability—not just a download button.
Risk: incomplete disclosure
The product principles
Every principle answered a risk—not a trend.
- 01Provenance before polish
Keep source system and legacy MRN in the patient context.
- 02Recognition before recall
Preserve familiar clinical categories and counts in navigation.
- 03Density is a preference
Let scanning-heavy and reading-heavy roles choose different views.
- 04Administrative work is product work
Permissions, disclosure, and configuration belong in the core experience.
03 / Three design decisions
The interface explains itself through context.
Instead of adding more instruction, we kept the patient, source, and permitted actions visible at the moment each decision was made.
Decision 01
One patient header that never loses context.
The header keeps identity, source system, legacy MRN, demographics, and workflow actions stable while the record changes beneath it.
Signal
Records can span multiple sources and identifiers.
Response
Persistent patient context + source badges.
Decision 02
Dense table or readable cards—not an awkward compromise.
HIM specialists scan many rows; clinicians inspect one encounter deeply. A remembered view switch supports both modes without forcing a lowest-common-denominator layout.
Signal
Scanning and comprehension pull density in opposite directions.
Response
Role-friendly views with persistent preference.
Decision 03
Configure the archive around the hospital—not the other way around.
Administrators can choose which clinical fields appear for a source and resource. That accommodates uneven legacy data without multiplying one-off interfaces.
Signal
Each source arrives with different fields and naming.
Response
Reusable, drag-to-order column configuration.
04 / The miss
We treated Release of Information like an export. HIM treated it like the job.
Our first framing optimized retrieval and pushed disclosure into a secondary action. Pilot feedback exposed the gap: choosing records, preparing a release, tracking it, and proving what was sent is an end-to-end workflow.
V1 assumption
Find → Export
A utility action attached to a record.
Reframed workflow
Request → Select → Release → Audit
An asynchronous, traceable work queue.
What changed in the product
ROI became a first-class module with request queues, selection, customizable forms, disclosure logs, and asynchronous processing.
What changed in our practice
We now map the operational lifecycle—not only the screen where the user touches the data. In enterprise tools, the handoff is often the product.
05 / Proof & reflection
The result is a system of safeguards that still feels direct.
The final experience joins patient retrieval, clinical reading, administration, and disclosure without pretending the underlying data is simple.
Public product scale1 PB+
customer data archived
30+
EHRs managed by 314e’s archival experts
50+
legacy systems archived
100+
data extraction and conversion projects delivered
Scale metrics are reported by 314e on the current Muspell product page. They show product maturity and reach; they are not presented as causal UX outcomes from this design phase.
What we’re proud of
We made complexity inspectable.
The strongest part of the work is not visual minimalism. It is that Muspell keeps the awkward truths visible: where a record originated, which identifier belongs to which system, what a role can access, and what was released. In clinical software, clarity is a safety feature.