This guide is built for the moment when WC has crossed from a payer-mix line item to a service line with a real growth target, and the tools that worked at the old volume are starting to crack. The frame is strategic. The lens is operational. At the end is a vendor-evaluation workbook, co-developed with DMOS Orthopaedic Centers, that you can send to your shortlist and use to score them side by side.

The four levers a growing WC program is actually pulling

Most evaluations start with a feature list and end with three vendors clustered inside a two-point spread. The reason is that the feature list is unweighted. Every capability gets equal voice, and the ones that actually drive the program get drowned out by the ones that look good in a demo.

A growing WC service line is pulling on four levers, not eighty.

The first is capacity without proportional headcount. You can't keep adding coordinators every time volume ticks up. Then there's response speed, because adjusters and NCMs route cases to whoever answers first. If you're slower than the orthopedic group across town, the case goes there. Lever three is institutional memory that survives turnover. A WC program runs on a coordinator's mental rolodex of which adjuster prefers what update cadence and which employer needs the report formatted a particular way. When that coordinator leaves, three adjuster relationships leave with them unless that knowledge lives in the system. The last lever is cleaner claims and shorter time to revenue, which is the financial output of getting the first three right.

Every capability you score belongs to one of those four levers, or it doesn't matter.

The workload math you're trying to change

At DMOS, the coordinator team logs roughly 357 administrative hours per month across nine workflow categories: IME, causation, impairment ratings, deposition correspondence, biologics, PSR/POWC/RTWC notes and auth, second opinions and transfers of care, new patient intake, and procedure referrals. That's the workload analysis Kelli presented at the 2026 AAOE Annual Conference.

About 51% of that time concentrates in two buckets, intake and repetitive stakeholder updates. Adding new patients, transferring documentation between the EMR and stakeholders, sending status updates, requesting authorizations, sharing authorization info with clinical teams, and checking case statuses. None of it is hard. All of it is repetitive. And it's where the entire platform conversation lives.

Your numbers will be different. The proportion is usually not.

The four requirements that actually move those levers

These are the platform requirements that show up against the four levers above.

1. Automated stakeholder communication

A WC case has more parties than any other case in the practice. Adjuster, nurse case manager, employer, attorney, patient, sometimes a TPA, and your own clinical team. Every party wants a status update, and every status update is currently a phone call or an email a coordinator sends by hand.

This is where the program stalls as it scales. Volume doubles, communication load triples, and the team starts triaging. The adjusters who don't get a callback stop sending cases. That's how response speed (lever two) compounds either for or against the program.

What the platform should do:

• Send automatic updates to the right stakeholders without anyone clicking a button. Configured to status (referral received, appointment scheduled, visit completed, work status issued, RTW plan finalized) and by stakeholder type.

• Tie all messaging to the case record so the communication history doesn't live in three coordinators' Outlook folders.

• Send patient confirmations for receipt and appointment details, with self-scheduling links where the workflow supports it.

A useful thing to look at during evaluation is the notification configuration UI itself. Ask to see the actual screen a coordinator uses to add or edit a milestone trigger. If configuration requires a support ticket, the automation runs on whatever the vendor's services team has time to set up, which is a different operational reality than a system the team owns.

2. Passwordless self-serve partner access

Adjusters and NCMs already manage a dozen logins and they keep losing the passwords. Every status check that requires a password reset turns into a phone call. Multiply that across the top twenty referral sources and a portal that demos beautifully ends up unused in production.

The portal that gets used is the one that doesn't require remembering anything. Magic link access by email is the practical bar in 2026. Adjuster gets an email, clicks the link, sees the case, uploads documents, leaves.

Security review is where these implementations sometimes get held up, so it's worth knowing what the IT team will look for. A magic link implementation should include short link expiry (typically 15 to 60 minutes), a full audit trail of who accessed what and when, and ideally optional IP or domain restriction for high-sensitivity stakeholders. A vendor who can walk through that architecture in writing is going to clear the security review faster than one who can't.

Beyond access, the portal needs to do real work, which means self-serve case status, document download, and document upload, plus a usage log so you can see which adjusters and NCMs are logging in. Portal adoption by your top referral sources is a leading indicator of whether the relationship is getting stickier or thinner. Usage data from real customers (logins per partner per month, percent of top-decile referral sources active in the last 30 days) is more useful in evaluation than a screenshot of the login page.

3. WC-native workflow, not a commercial referral with extra fields

The clearest way to tell whether a platform was built for WC or had WC bolted on later is to ask what happens to an IME report.

In a WC-native system, the IME report has its own document type. The platform recognizes it on intake, routes a copy to the adjuster portal, attaches the original to the case record, triggers a notification to the requesting party, and updates the case status. In a generalist platform retrofitted for WC, the IME report comes in as "medical record," gets attached to the patient chart in the EHR, and waits for a coordinator to manually email a copy to the adjuster. So the work happens twice. The adjuster waits. The case sits.

That's one example of a much larger pattern. WC has its own document taxonomy (referral order, authorization, claim file, IME, impairment rating, deposition correspondence, RTW plan), its own intake fields (employer contact, adjuster, NCM, attorney, claim type, date of injury, body part, employer payer), its own stakeholder graph, its own closure conditions (work status resolved, rating paid, documentation delivered), and its own attribution model (revenue by adjuster, by employer, by NCM, not just by referring physician). A platform built natively for WC handles each of those correctly out of the box. A platform that's been adapted for WC tends to need configuration workarounds that the coordinator has to maintain.

The diagnostic in the demo is to walk through what happens to a specific WC document type from inbound fax to closed loop. The vendor's answer reveals more about the architecture than any feature list.

4. EHR integration the vendor owns end-to-end

EHR integration is table stakes, and it's where most platform deployments quietly stall.

The pattern looks like this. The vendor lists a half-dozen EHRs as supported. Six months in, the IT team is still hand-rolling HL7 mappings, coordinators are double-entering patient demographics because the chart-creation push doesn't fire reliably, and "bidirectional" sync is bidirectional in slide-deck language and one-way in production. The integration that gets sold and the integration that gets delivered are different things, and the gap shows up in the coordinator's daily work.

What the integration needs to do in production:

• Run in both directions. Patient charts created in the platform appear in the EHR. Documents processed in the platform push to the patient chart in the EHR. Referral closure in the platform closes the referral in the EHR. Activity notes sync.

• Be the vendor's responsibility, not yours. The vendor owns setup, configuration, testing, and go-live. Your IT team provides access and credentials. If the integration is structured as "give us an HL7 feed and we'll figure it out," your IT team will be doing the integration work for the vendor.

• Cover the data flows in regular use, not just patient demographics. Patient creation, document sync, referral status updates, appointment tracking, activity notes. A list of supported data flows in writing is more useful than a logo wall of supported EHRs.

Two related items fold in here. Multi-site support (location-level controls, team-based workflows, consolidated reporting from day one, because retrofitting multi-site after the fact is a six-figure project) and referral source attribution down to the employer level (a platform that can tell you which top-five employers, adjusters, and NCMs drove the most revenue last quarter is the platform that helps you decide where to invest in relationships next year).

A useful artifact to ask for here is an implementation timeline as a milestone list rather than a "typical timeline" range, plus the percentage of recent customers who hit go-live on schedule and a reference customer who can speak specifically to the integration build.

Where evaluations usually go wrong

Most platform evaluations look the same on paper. The vendors all answer the questions, the answers all sound reasonable, and the differences live in the gap between what's described in writing and what's running in production. Four patterns are worth knowing in advance, because they're where the evaluation tends to lose its shape.

The first is roadmap inflation. The line between "we're building it" and "it's in production" can blur in vendor responses, especially around features the buyer is most focused on. On a 0-3 scale (0 = not available, 1 = partial or roadmap, 2 = in production, 3 = advanced with reference customers), the gray area between 1 and 2 is where ambiguity tends to collect. A useful clarifier is to ask for either a screen recording of the feature in production at a real customer or a named reference who's using it. If neither is available, it's a 1.

The second is automation that isn't quite automation. "Automated" is the most overloaded word in the category. Sometimes it means the platform sends an email when a coordinator manually changes the status, which is a notification on a manual action rather than automation. True automation is the platform detecting state change from inbound data (a document arrives, a status is parsed from the document, a notification fires, a workflow advances) without a coordinator clicking anything. Asking the vendor to walk through one specific automation end to end and identify every human-in-the-loop step usually surfaces the difference quickly.

The third is the demo-vs-production gap. Demos run on prepared data in clean tenants. Production runs on a fax queue at 4pm on a Friday. The useful questions are about real conditions. What does the average customer's first-month adoption look like, what does support load look like in months one through three versus month twelve, and which features do customers turn off after go-live. Vendors who track those numbers tend to be paying attention to whether the product is working in production, which is the more telling signal.

The fourth is reference selection. Reference lists are usually curated, which is reasonable but worth working around. A more useful version of the reference call is one that meets specific constraints, an orthopedic group of comparable size, in growth mode on WC, with WC at more than 10% of payer mix, on the same EHR you run. Three of those four constraints should produce a real reference. If a vendor can't produce one, that's information too.

How to run the process

Two practical points compound across the evaluation.

Send the same written questions to every vendor. Sales calls are good for chemistry and bad for comparison. The goal is to have each vendor scoring themselves on the same capability list, in the same format, so the differences are visible side by side. A structured evaluation also surfaces how a vendor approaches process work, which is useful information for the implementation that follows.

Weight the critical items more heavily than the totals suggest. A vendor with a strong total but a 0 on automated notifications, EHR integration, or magic link access is going to leave the team working around that gap for the next three years. The summary score smooths out the cost of those gaps, but the daily work doesn't.

The workbook

We built a vendor evaluation workbook with Kelli and her team at DMOS. It covers the full set of questions an orthopedic group typically wants to work through before signing a WC platform contract. Six categories, 27 capability requirements, a 0-3 scoring scale, an auto-calculating summary tab.

Download the workbook here, send the evaluation tab to each vendor on your shortlist, and score them side by side.

If Hatch ends up on that shortlist, we're happy to walk through how we score against the same criteria.