Clinics often want a better front door for patients without taking on the risk of replacing the EHR. That is a reasonable boundary. An access layer can improve booking, arrival, intake, and queue visibility while the EHR remains the system of record.
The challenge is evaluating that layer as an operating modelnot just as a scheduling screen. The right questions cover interfaces, workflow ownership, privacy, and what happens when several sites share staff or services.
Start with an overlay model
A useful architecture is an overlay around the EHR:
- FHIR R4 for the shared language: Use standards-based resources and APIs where the EHR exposes them. Appointments, schedules, locations, practitioners, and patient-facing workflow references should have clear ownership and identifiers.
HL7 v2 where the organization already depends on it: ADT, SIU, and other messages may still arrive through an interface engine. The access layer should handle acknowledgements, retries, ordering, and reconciliation rather than treating a message as a one-time import.
A deliberate boundary: The access application manages the experience and operational state it owns—such as a booking request, check-in event, or queue status—while the EHR remains authoritative for clinical and registration data as agreed with the organization.
Ask vendors to draw this overlay with your integration team. Look for data direction, system of record, failure behavior, and the identifiers used to correlate events. “We integrate with the EHR” is not enough; a useful answer shows what is read, what is written, how conflicts are handled, and how an operator knows an event needs attention.
Trace the whole patient-access flow
Evaluate a realistic path from booking to reporting rather than reviewing features in isolation:
- Booking: Can a patient or staff member find the correct service, location, and availability? Check rules for new versus returning patients, rescheduling, cancellations, reminders, and duplicate requests.
- Check-in: Consider web, mobile, front-desk, and kiosk entry points. The workflow should support identity and appointment matching without asking for more information than the task requires. Provide a clear path for exceptions, accessibility needs, and staff assistance.
Queue: A queue should represent an operational handoff, not pretend to be a clinical decision. Check whether staff can see the next appropriate work item, update status, record a reason for a delay, and recover gracefully from a disconnected device or an integration outage.
Analytics: Confirm that events from booking, arrival, and queue transitions can be reported with consistent timestamps and definitions. Useful dashboards explain where work is waiting and how a site can investigate an exception; they should not require copying patient records into a separate spreadsheet.
Walk through this flow with schedulers, front-desk staff, clinical operations, and IT. Their questions will expose gaps that a product tour can hide.
An evaluation checklist
Integrations. Request a current interface map and a test plan. Ask which FHIR R4 capabilities are used, which HL7 v2 messages are supported, whether an interface engine is required, and how retries, duplicates, downtime, and reconciliation work. Verify sandbox access and who owns monitoring.
Privacy posture. Review data minimization, role-based access, audit trails, retention, export and deletion processes, encryption, subprocessor transparency, and incident-response responsibilities. Confirm that non-production environments use synthetic data. Avoid any evaluation that requires pasting real patient information into a vendor demo.
Multi-site capacity. Model separate locations, departments, hours, time zones, holiday calendars, service-specific rules, and staff who work across sites. Ask how configuration is inherited, how local exceptions are approved, and how reporting distinguishes a site from an enterprise view. Capacity is an operating question: include peak arrival patterns and outage procedures, not only the number of user accounts.
Kiosk and intake. Test the physical and digital experience. Can a kiosk recover after a reboot, support multiple languages or accessibility settings, and hand off to staff without exposing information to the next person? For digital intake, check field-level validation, save-and-resume behavior, consent handling, and whether unnecessary clinical detail is collected before it is needed.
Operations and exit. Define service ownership, support hours, change notifications, status communication, data export, and termination assistance. A small proof of concept should include an interface failure, a corrected appointment, a manual override, and a report reconciliation—not just a successful happy path.
Make the decision reversible
Set acceptance criteria before a pilot. For example: every test event has a traceable identifier; staff can resolve an exception without engineering help; the kiosk does not retain a prior user’s information; and reports agree on the meaning of booked, arrived, and completed. Keep the EHR workflow available during testing and document who approves production changes.
The strongest choice is not necessarily the tool with the longest feature list. It is the access layer that fits the clinic’s existing architecture, makes boundaries explicit, and gives staff a safe way to recover when the real world does not follow the happy path.
Disclosure: I work with TSB HealthCare, which focuses on patient-access workflows. This article is an independent, practical checklist—not a claim about any specific customer outcome.
If you are mapping an access layer around an existing EHR, learn more at https://www.tsbhealthcare.com/ or request a conversation at https://www.tsbhealthcare.com/book-a-demo/.
Top comments (0)