Designing a Digital-First Hospital Check-In Service
How service design research reframed a kiosk rollout as a system problem — and gave Geisinger leadership the strategy behind a check-in program that scaled across Pennsylvania within a year.
Context
Geisinger had a problem visible on both sides of the front desk. Staff shortages were straining check-in: patients waited longer, and Patient Access Representatives (PARs) absorbed a growing load of verification, payment, and troubleshooting work. Patient satisfaction and employee engagement were falling together — which told us the front desk wasn't the problem, it was where the problem surfaced.
Leadership's plan was to pilot self-service kiosks at two campuses, Woodbine and Muncy. Our team was brought in ahead of that rollout with a brief: identify the pain points and bottlenecks in the current system, and develop strategic recommendations for a digital-first check-in solution.
I joined a team that included a Service Designer, Reenu John (Experience Design Lead), and Hospital leadership, Rebecca A. Stametz (Vice President Innovation & Strategy).
Snapshot
Role
Service Designer / Design Strategist
Timeline
8 weeks
Project Type
Team
0→1 pilot strategy · Research planning · stakeholder interviews · observational studies · workflow analysis · affinity mapping · service blueprinting
Experience Design Lead· Service Designer · VP of Digital Transformation
Core Challenge
Initial framing
Geisinger identified the need to improve the hospital check-in experience. The issue was not only about patient convenience. Staff shortages were affecting both patient satisfaction and employee engagement.
Reframing the Problem
The organization wanted to explore a more digital-first check-in model using kiosks. But in a hospital environment, a kiosk is not just a piece of technology. It changes the work around the front desk, data verification, payment collection, staff responsibilities, and downstream revenue workflows. If the structures around the kiosk didn't change with it, the kiosk would shift burden rather than remove it — and adoption would stall no matter how good the touchscreen was.
So the core challenge was not simply:
Can patients use a kiosk?
The more important service design question was:
what has to change across people, process, and technology for digital check-in to work as a service — and survive scaling?

My Role
My main contribution was helping make the operational complexity visible. I focused on connecting what patients experienced at check-in with the backstage realities of staff workload, data verification, payment collection, system limitations, and department-level priorities.
My responsibilities included:
Planning and designing user studies.
Synthesizing findings into insights.
Understanding the current check-in model.
Developing proposed service maps.
Since we were a remote team, all the messy work happened in Miro!
How We Structured the Work
Phase 1: Research and Current-State Understanding
The first six weeks focused on understanding the existing check-in experience through secondary research, research planning, stakeholder interviews, observational studies, contextual inquiry, workflow analysis, and current-state service mapping.
Phase 2: Insight Delivery and Service Recommendations
The final two weeks focused on translating the research into usable outputs: an insights document, a one-page leadership visual, and a proposed-state service blueprint.
How I Designed the Research
Because this was a hospital environment, the research had to be practical. We had tight timelines, limited participant availability, privacy constraints, and busy staff. So instead of designing a heavy research process, I helped shape a lightweight approach that could fit into the organization’s reality.

I built the plan and the guide, my teammate, Kevin Hall brought it into the field!

_edited.jpg)
_edited.jpg)
_edited.jpg)
Research and observation studies with PARs, hospital staff at Woodbine (Derm, Peds, CMSL, Ortho, Labs) and Muncy Campuses
Three Tensions
The research showed that digital check-in was being limited by three tensions.
Patient confusion
There were too many check-in options. Patients were not always sure which path to take, when to use the kiosk, or when to ask for help.

Staff burden
Patient Access Representatives were still responsible for verification, troubleshooting, payment conversations, and helping patients move through the process.

System misalignment
Workflows and department responsibilities were not fully aligned. This meant the kiosk could reduce some work, but it could also expose or shift work elsewhere.

What the Mapping Revealed
The work took shape through three layers: analyzing interview data, mapping the current service, and developing insights that moved beyond symptoms.
Current-state mapping
I mapped the existing check-in journey end to end — patient actions, frontstage and backstage staff actions, and the systems behind each step. The blueprint made one thing immediately visible: the heaviest staff dependency sat at demographic data verification, where PARs juggled multiple platforms (EPIC, scanning, insurance verification, payment processing) for a single check-in. Payment collection was similarly fragmented, with certain payment types simply falling through the cracks.

Highest Staff dependency due to data verification.
Snapshot of service blueprint for the current checkin process
Insight synthesis
Using affinity mapping and 5-Whys root cause analysis, I helped group the five issues into three system-level themes: governance (who owns the check-in experience when PARs report to departments with conflicting priorities), operational efficiency (workflows and technology that don't fit how the work actually happens), and training and communication gaps (staff asked to collect payments without being equipped for those conversations).

Working sessions checking our early insights with the teams closest to the check-in experience. — digital transformation and PAR leadership!

Two framing decisions mattered as much as the content:
Sequencing for credibility, not ambition.
Data quality went first as the short-term priority — concrete, measurable, achievable inside existing operations. Centralized governance, the deeper fix, was positioned long-term, because opening with "restructure your org" is how recommendations get politely shelved. Give leadership a win they can start Monday, and the structural conversation stays alive.
Anchoring on the rails Geisinger already owned.
The strategy was built around three check-in methods already in the Epic ecosystem, each with its honest costs: not every patient demographic is comfortable with self-service; some verification stays at the front desk; payment workflows still lean on PARs. Recommendations that hide their tradeoffs read as advocacy; recommendations that surface them read as analysis. Operators trust the second kind.
Making the Strategy Travel
The recommendations would be carried by Innovation leadership into conversations with IT, Data, Product, Operations, and Revenue Management, mostly without a designer present.
So I designed the one-page leadership visual around a metaphor instead of a framework diagram: a digital solution is like a city — it only functions when the infrastructure underneath it (people, process, tech/data) works together. Each stakeholder group appeared in it with their own voice — revenue management ("I need the right data at the right time so we can get paid"), patients ("I just want to check in quickly"), operations ("we need to reduce dependency on staff") — so every reader found their problem on the page before they found our answer. That page became the artifact leadership actually used.
Proposal: Service Blueprint for a kiosk based check-in experience.
I translated the strategy into a future-state blueprint: the kiosk positioned to handle routine check-in — identity, demographics, forms, biometric check-in — earlier and more consistently, cutting PAR dependency for data collection and shrinking the downstream revenue work queues that bad data creates. Not a screen design; an operating model the organization could build toward.
.jpg)
Reduces PAR Dependency for data collection and verification
What I'd Take Further
1. Define the metric stack before launch — and own the definitions.
A pilot's headline number means little without the funnel underneath: kiosk completion vs. abandonment, staff-assist rate, time-to-check-in against the front-desk baseline, payment capture at the kiosk. I'd agree metric definitions with the analytics team before day one, so every number that reaches a leadership meeting can be traced to how it was measured.
2. Segment the non-adopters.
Our research flagged that some demographics weren't comfortable with self-service — but "won't use it," "couldn't find it," and "tried it and bailed" are three different problems with three different fixes. I'd push for adoption data cut by age group, visit type, and time of day, and target interventions instead of guessing.
3. Close the loop to the business case.
The kiosk's promise was reduced PAR dependency and cleaner data earlier. I'd define the downstream measures — PAR time freed, registration error rates, revenue-queue volume — and track whether kiosk check-ins moved them. That evidence is what turns a pilot into a funded program, and it's the part of this work I most wanted to own.
Key Learnings
1. Digital adoption is a service problem, not just a technology problem.
The kiosk only worked when the workflow around it supported patients and staff.
2. Service design is most valuable when it makes hidden work visible
A lot of the friction was not obvious from the patient's side. Mapping the helped reveal how much hidden work PARs were carrying.
3. Good recommendations need to travel across teams
The insights had to be clear enough for Innovation leadership to use in conversations with IT, Data, Product, Operations, and Revenue teams.
Here is what I discovered through the work.
