Occupational Health Software: Where Protocols, Surveillance Clocks and Employer Billing Break

Why occupational health software makes or breaks a multi-site provider

It is 6:50 a.m. and a third-party logistics client has sent 14 new hires to your east-side clinic for post-offer physicals. Your front desk lead pulls the laminated sheet for that account out of a three-ring binder: 10-panel non-DOT urine screen, audiogram, respirator questionnaire per OSHA 1910.134 Appendix C, and a lift test to 50 pounds. What the sheet does not say is that the client added a second job class in March, and the six people standing in the lobby for the freezer role also need a cold-stress screen. Nobody catches it. Two weeks later the employer's safety manager calls, and you bring all six back and eat the cost, because the contract says the protocol is your job to know.

That is the actual shape of the work. Occupational health is not primary care with a different waiting room. The patient is the employee, the customer is the employer, the payer is sometimes the employer directly and sometimes a workers comp carrier like Sedgwick or Gallagher Bassett, and the thing you are really selling is a defensible record delivered on a deadline. Meanwhile your systems were built for none of that. Net Health Agility and SYSTOC understand employer accounts but bend slowly. Enterprise Health handles surveillance well and integrates poorly with the rest of your stack. And if you grew out of urgent care, you are probably running eClinicalWorks or athenahealth, which model the payer as an insurance plan and treat "employer" as a free-text field.

So the gap gets filled by people. A coordinator maintains the surveillance spreadsheet. A biller rekeys eScreen results. A medical assistant faxes work status reports. At a four-site provider we worked with, three full-time staff existed purely to move data between systems that already had the data. That is three salaries spent on copy and paste, before you count the re-dos, the missed recerts, and the national account you lost because you could not give their safety director a login.

Problem: the employer is the customer, but your chart says the patient is

Here is the scenario that exposes it. A regional manufacturer has 11 plants, 40-odd job classes, and a safety director who wants one invoice, one dashboard, and clearance results within four hours of the exam. In eClinicalWorks or athenahealth, you cannot express that. There is no object for "employer," no object for "location," no object for "job class," and no object for "protocol." So you fake it with appointment types named ACME-WAREHOUSE-PHYS and a spreadsheet mapping them to price.

General EHRs cannot fix this because their core entity is an encounter attached to a patient attached to an insurance plan. Occ-med-specific tools like Agility and SYSTOC do model the employer, but the hierarchy stops shallow, and adding a client-specific rule means a support ticket and a release cycle you do not control.

A custom build starts the data model at the employer, not the patient: Employer to Location to Department to Job Class to Protocol Version, with an effective-dated rate card hanging off the contract. Protocols are versioned records, not documents. When the safety director adds the freezer role in March, they add it in the portal, it takes effect on a date you both see, and every check-in for that job class after that date auto-builds the correct service list. Your front desk stops deciding. There is also a legal reason to build it this way: under the ADA, employee medical records must live separately from personnel records, and the employer is entitled to the fitness determination, not the diagnosis. A custom permission layer enforces that at the field level. A generic EHR's "share the chart" button is a compliance incident waiting to happen.

Problem: the compliance clock runs in a spreadsheet

Every occ health provider has a version of the same file. Tabs by employer, columns for audiogram due, respirator clearance due, CDL cert expiry, chest x-ray, titer. Someone updates it on Fridays. When they take PTO, the clock stops. Then a driver shows up on day 731 with an expired card, and your client's truck sits.

Net Health Agility and Enterprise Health do run recall logic, but it is anchored to a service performed at your clinic. Half your reality is not that: the employee had an audiogram at a prior employer, the baseline came in on a fax, the respirator clearance was done by a mobile vendor. The tool has no way to hold an external event as a first-class fact, so the spreadsheet survives.

Build the clock as its own service. Every requirement is a rule with an interval, an owner, and a source, and it accepts an event from anywhere: your exam, an uploaded PDF, an HL7 result from Quest or LabCorp, an eScreen callback. AI is worth the line item at exactly this point in the flow. A document extraction pipeline reads the inbound fax or PDF, pulls the audiogram thresholds or the certificate expiry, and posts the event with a confidence score. Anything under threshold goes to a human review queue instead of rotting in a shared drive. Then run the math the standard actually requires: an OSHA standard threshold shift is a 10 dB or greater average shift at 2000, 3000 and 4000 Hz in either ear against baseline, with the Appendix F age correction applied only if you elect it. Coding that once, correctly, ends an argument your audiometric tech has been having with your medical director for years. Layer on forecasting: the same rule engine can tell you that 340 respirator clearances come due in Q3 at one client, so you staff for it and, more usefully, you invoice for it before your competitor calls them.

Problem: injury cases stall between the exam room and the adjuster

A press operator lacerates a hand at 2 p.m. Your physician sees him, sutures, writes restrictions of no lifting over 10 pounds and no wet work for seven days. The employer needs that in an hour to make the return-to-work decision that keeps the case non-lost-time. The adjuster needs a Texas DWC-73 or a California PR-2 depending on the state. Today: the doctor writes on paper, an MA scans it, someone faxes the employer, someone else keys the state form. Elapsed time, four hours on a good day. If that operator goes home instead of to light duty, the case becomes a lost-time claim and your client's experience mod moves.

Generic EHRs cannot fix this because restrictions are free text in a note. You cannot route free text, and you cannot report on it.

Model restrictions as structured data: body part, activity, limit, duration, effective dates, review date. The moment the physician signs, three things fire in parallel. The employer contact gets the fitness-and-restrictions summary only, no diagnosis. The state form is pre-populated from the same structured fields and queued for signature. The case opens with a follow-up date and an owner. AI does the drafting work nobody wants: it turns the clinical note into the employer-facing status narrative, in your house voice, for the physician to approve in about 20 seconds. It also drafts the follow-up outreach when a case goes past its review date with no contact, which is where cases turn expensive.

Problem: you bill three payers with one rate card, and you leak

Occ health billing is three businesses in a trench coat: employer direct-bill against a negotiated rate card, workers comp against a state fee schedule such as the California OMFS or the Texas medical fee guideline, and the occasional group health claim. Your practice management system knows how to do one of those. The other two live in spreadsheets and a biller's memory.

The leak is specific and it is measurable. Services rendered but never invoiced because they were not on the appointment type. Panels priced at last year's rate because the contract renewed in January and the rate card in your PM did not. Re-dos billed to nobody. When we instrumented this for a five-site provider, the gap between services documented and services invoiced was in the high single digits of monthly revenue. That is not a nice-to-have.

A custom build ties the charge to the protocol, not to the front desk's memory. Every service on the executed protocol generates a charge line at the contract rate in force on the date of service. A reconciliation job runs nightly and flags any documented service with no charge line, and any charge line at a rate that does not match the active contract. Two people stop chasing, and one report tells your CFO exactly where the money went.

Problem: employers book when you are closed, and surge when you are open

Employer schedulers are HR (Human Resources) generalists working at 9 p.m. after the interviews are done. Your phones are off. So they email a list of eight names to a shared inbox, and your team spends the first hour of the day turning email into appointments, which is how 14 people end up in your lobby at 6:50 with no protocol attached.

Consumer scheduling layers like Solv or Clockwise.MD were built for a person booking themselves, not an HR coordinator booking a cohort against a contract. They cannot check whether the employer has an active protocol for that job class, or whether the account is on credit hold.

Give the employer a real portal: submit a roster, pick the job class, and the system builds each visit's service list from the current protocol, checks capacity across your sites, and returns confirmed slots. Behind it, an AI intake agent handles the after-hours channel that already exists, meaning the email and the phone call, parses the roster, matches employees against your existing records, and books it. Anything ambiguous, such as a job class that does not exist or a name that matches two records, escalates to a queue for the morning rather than guessing. The point is that the protocol is attached before anyone drives to your clinic.

What this costs and how long it takes

These are Digital Heroes delivery bands from 2,000+ projects, not a market survey. A focused first release, meaning the employer and protocol engine, structured clearance decisions, and the compliance clock with document extraction, typically runs $60k to $130k and ships in 12 to 16 weeks. A full platform adding lab and drug screen interfaces, injury case management with state forms, the employer portal and contract-driven billing runs $150k to $400k phased over 6 to 12 months.

What pushes you toward the top of the band in this category, specifically:

• Lab and screening interfaces. Each one is real work. Quest and LabCorp HL7 result feeds, eScreen or i3screen for chain of custody and MRO outcomes, and any FormFox-style collection site flow. Budget per interface, not per project.
• Multi-state workers comp. One state's forms and fee schedule is a feature. Six states is a subsystem, and it needs an owner after go-live because the schedules change.
• DOT. Certified examiner workflow, MCSA-5875 and MCSA-5876 handling, and next-calendar-day reporting to the FMCSA National Registry. Getting the deadline logic and the audit trail right is not where you improvise.
• Migration. Pulling 10 or 15 years of history out of SYSTOC or Agility, especially audiometric baselines, is usually the single most underestimated line item. Assume 3 to 6 weeks and insist on a dry run against production data.
• Security posture. HIPAA is table stakes. If you are chasing national accounts, they will ask for SOC 2, and that changes your architecture and your timeline, so decide up front.

Build or buy: take the honest read

Buy if you are one or two sites, under about 15 employer contracts, and your mix is DOT physicals, drug screens and minor injury care. Agility or SYSTOC will hold that, your protocols fit in a binder because there are 20 of them, and a custom build is a distraction from hiring another provider. Buy also if your growth plan is to be acquired in 18 months, because the acquirer will migrate you onto their stack anyway.

Build when these show up, and they show up together. Three or more sites with protocols that differ by client rather than by service. A named person whose job is the spreadsheet. A prospect that asked for a portal and picked someone else. Contract revenue past roughly 40 percent of the top line, meaning the employer relationship is the business and the software should express it. And the tell that settles it: your best clients are asking for reporting you cannot produce without a week of manual work. At that point the off-the-shelf tool is not saving you money, it is capping your enterprise value, because the differentiated thing you sell, which is protocol accuracy and speed to the safety director, is the exact thing the vendor cannot let you customize.

How to choose a developer for occupational health software

Vet for four things, and be unkind about it.

Make them draw the data model on the call. Ask for the entities and the relationships between employer, location, job class, protocol version, service, rate card and clearance decision. If the first shape they draw is patient-centric, they are going to build you an urgent care EHR with an employer field, and you will find out in month five.

Ask what happens when a protocol changes mid-year. The correct answer involves effective-dated versions and visits resolving against the version in force on the date of service. A wrong answer is "we update the template." That single question separates people who have shipped this from people who have read about it.

Ask for a named interface they built, not a logo slide. HL7 result ingestion from a reference lab, an eScreen callback, a National Registry submission. Ask who owned the error queue after go-live, because interfaces do not fail loudly, they fail on the small share that does not match, and that share is somebody's expired card.

Get the compliance and ownership terms in writing before kickoff. BAA signed, ADA-driven segregation of employee medical data designed in rather than bolted on, and full source code plus infrastructure ownership in your name from day one. If a developer hesitates on code ownership for a system this close to your contracts, that is the whole answer.