If you run a university speech clinic, you've probably already tried a speech therapy EMR that technically works but wasn't built for you. The features are there — scheduling, notes, maybe billing — but the permission structure assumes one clinician with full record access, the onboarding process assumes that same person stays indefinitely, and there's no native way to manage a supervisor review queue. You adapt. You build workarounds. And every semester, you do it again.
That's the core problem with applying a speech language pathology program EMR designed for private practice to a university training clinic. The two environments look similar on the surface — clinicians, patients, documentation — but they operate on fundamentally different logic. Rotating student cohorts. Tiered supervision requirements. ASHA accreditation oversight. Dual FERPA and HIPAA compliance. A new crop of students who need restricted access every August and January.
This post walks through what makes university clinic documentation different from private practice, which features to evaluate in any platform, and the questions worth asking before you ever request a demo.
Why Most SLP Clinic Software Wasn't Designed for University Training Clinics
The major players in speech therapy EMR software — SimplePractice, TheraPlatform, WebPT, Fusion — were designed around one primary user type: a licensed clinician in a single practice with full access to all records and a stable user base that doesn't turn over every five months. Every feature decision, permission structure, and onboarding flow reflects that assumption.
University programs introduce three structural requirements these platforms simply don't support natively. First, students should only be able to see their assigned patients, not the full patient list. Second, supervisors need a structured way to review and co-sign student documentation — not just the ability to add a signature after the fact, but a workflow that surfaces what's pending. Third, onboarding needs to repeat, predictably and efficiently, every semester.
Without those features, programs build workarounds. IT manages student accounts by hand, deactivating the old cohort and setting up the new one from scratch twice a year. Supervisors track co-signature status on spreadsheets or handwritten checklists. Clinical documentation and hours logging run on separate systems — CALIPSO on one screen, the EMR on another — with no integration between them.
Every workaround is a compliance liability. When a CAA site reviewer asks to verify co-signature completion rates across all students for the past semester, "let me go through the records manually" isn't an acceptable answer. And it's an avoidable one.
The ASHA and CAA Documentation Requirements Driving the Administrative Load
The documentation burden in university SLP programs isn't arbitrary. It flows directly from accreditation requirements that are specific, measurable, and non-negotiable.
ASHA requires a minimum of 400 supervised clinical hours for graduate SLP students, with at least 25% of each student's total client contact directly supervised.1 That supervision percentage has to be documented at the session level. You can't approximate it at semester-end and hope the math works out.
All student clinical documentation must be co-signed by a supervisor holding an active CCC-SLP certification with at least nine months of post-certification clinical experience.2 That's not a suggestion — it's a requirement with a timeline attached. A note from two weeks ago that's still waiting on a supervisor's signature isn't compliant, and discovering it on a Friday afternoon before a deadline creates exactly the kind of fire that no one needs.
The CAA standard revisions that took effect October 1, 2025 added new curriculum documentation requirements for all programs completing annual reports or accreditation applications after that date.3 Whether your current platform can generate the data points those revised reports require is a practical question worth answering now, not during your next accreditation cycle.
Then there's the CALIPSO gap. Nearly 86% of SLP programs use CALIPSO for clinical hours tracking,4 but CALIPSO is not an EMR. It tracks clock hours — it doesn't store session notes, generate billing records, or flag SLP student documentation gaps. Programs using CALIPSO alongside a separate clinical platform are manually reconciling two data systems. That duplication adds time and creates opportunities for data to fall out of sync.
University-Specific Features to Evaluate in Any Speech Clinic EMR
When you're evaluating a university speech clinic EMR, the feature list that matters most is shorter than you'd expect — but each item on it is a dealbreaker.
Student caseload restrictions. Ask every vendor directly: does your platform support patient-level access scoping by user? Students should only have access to their assigned patients, not the full patient list. If the answer to this question involves a manual workaround, that's the answer.
Supervisor co-signature and review workflows. You're looking for a structured queue — not just the ability to add a signature, but a workflow that notifies supervisors when student notes are ready for review, tracks completion status, and gives clinic directors a way to see what's pending across the whole caseload. A supervisor who has to hunt through individual records to verify note completion is a supervisor who will eventually miss something.
Role-based permissions across all user types. Faculty, clinical supervisors, adjunct supervisors, graduate students, and administrative staff each need different levels of access. Granular, configurable permission sets should be standard. If a platform offers two tiers — admin and clinician — it wasn't built for your environment.
IP address restrictions and multi-factor authentication. University IT departments often require platform access to be limited to campus networks or approved IP ranges. Ask vendors whether they support this and whether it's included in the base price. MFA should be a given, not an add-on.
Cohort-ready onboarding. The same group of 20 to 40 students doesn't stay in your clinic forever. The platform should make semester-over-semester onboarding efficient — not require the same setup process from scratch every time a cohort rotates.
On-demand reporting for accreditation. When CAA asks for co-signature completion rates, direct supervision percentages, or documentation compliance data, the system should generate that report in a few minutes. If the answer is "we'll need to export the data and build the report ourselves," that's a cost you'll pay every year.
Scheduling and Billing in a University Clinic Context
Scheduling and billing in a university clinic context don't look like they do in a private practice, and the therapy EMR you choose needs to reflect that.
On the billing side, many university programs use sliding-scale fees, operate under grant funding, or don't bill commercial insurance at all. A platform built for high-volume private-practice billing may have more billing infrastructure than you need — or it may have billing assumptions baked in that conflict with how your clinic actually operates.
Even programs that don't bill commercially often use student encounters to teach CPT code documentation and service code practice. That's valuable clinical training, and the EMR system should support it without requiring you to set up a full commercial billing workflow just to expose students to the process.
Scheduling complexity in university clinics is also real in ways a solo-practice scheduler won't handle. You're managing room assignments, supervisor-student pairing, and semester-based recurring appointment cycles simultaneously. Color-coded views, filtering by supervisor or room, and recurring appointment support aren't nice-to-haves — they're the features that keep a busy clinic week from turning into a coordination problem.
Integrated room reservation is worth particular attention. Without it, rooms get double-booked and schedules have to be reconciled manually. When room reservation is built directly into the scheduling module, that class of problem doesn't happen.
Making the Case to IT and University Administration
Program directors rarely make EMR decisions alone. IT, compliance officers, and department administration all have input, and each group comes to the conversation with a different set of concerns. Understanding those concerns before you walk into the room makes the approval process move faster.
IT will want to know whether the platform is HIPAA compliant, supports MFA, allows IP-based access restrictions, and where patient data is stored. Get clear answers in writing before bringing IT into the conversation. If the vendor has already passed a security review at another university, ask for documentation from that process — it's the fastest way to clear a significant portion of IT's checklist.
Administration's concerns are cost, implementation timeline, and training overhead. A 60-day full implementation timeline and a learning curve measured in hours rather than months are very different selling points than a six-month enterprise rollout. It's worth quantifying what your current workaround actually costs — how many hours per semester does IT spend managing student accounts manually? How much supervisor time goes into tracking co-signatures on a spreadsheet? Those numbers make the case for a proper solution more concretely than any feature comparison.
For compliance officers, the relevant questions are: Can the system generate the reports CAA requires for annual reporting? Does it support FERPA-layered access — not just HIPAA compliance, but the additional layer governing student education records? Can it produce an audit trail for co-signature completion?
One practical tip: don't accept a generic demo. Bring specific scenarios. Log in as a student and try to access a patient outside your assigned caseload. Submit a note and watch whether a supervisor review queue populates. Ask the vendor to build a custom report on the spot. How a vendor handles specific, university-clinic-shaped questions tells you more than any feature list will.
The Right Question to Ask Before the Demo
The question isn't really "which EMR is best for speech therapy?" It's "which speech therapy EMR was built for the training clinic environment?" That reframe narrows the field considerably — and gives you a clearer benchmark for evaluating everything you see in a demo.
Private-practice SLP software will always require adaptation in a university clinic. The structural gaps — student scoping, co-signature workflows, cohort onboarding, accreditation reporting — aren't features that can be patched in after the fact. They require an architecture that was designed for this environment from the start. Knowing that going in changes which questions you ask and which answers are acceptable.
Looking for an EMR built for university speech clinics? ClinicNote is used by 117 speech clinics and built specifically for university training environments, with student caseload restrictions, supervisor review workflows, and custom reporting included. Request a demo to see the supervisor and student workflows firsthand.
Sources
- https://www.asha.org/practice/supervision/SLP-graduate-student-supervision/
- https://www.asha.org/practice-portal/professional-issues/clinical-education-and-supervision/
- https://caa.asha.org/reporting/standards/
- https://www.calipsoclient.com/