Part 3: The ground changes underneath

Wow! you built your scheduling system, your killer iOS app continues to rack up 5-star ratings, and it configures to meet the reality of a complex clinical organization. So, are we done? No... this is a 4-part series, this is only part 3.

Let's fast forward a few months at your new client.

Month 3, the EMR says: "We updated our assessment workflow, acuity lives in a different field now." Your demand signal goes flat overnight. Nobody notices for 2 weeks.

Month 5, Payroll says: "We added a retention bonus pay code." Those hours land in a bucket your system has never seen, and your OT forecast is now wrong.

Month 8, HR says: "We're changing payroll systems." Every employee ID changes.

Month 9, a nurse says: "why does the schedule say I'm on Tuesday? I quit last week." The termination is in the HRIS, it just never made it to you.

Welcome to integrations. A great clinical scheduling system needs to integrate with a minimum of 2 other systems (sometimes more).

Clinical scheduling sits between the two core systems of record in nursing care: the EMR and the HRIS.

EMR = electronic medical record. The EMR tells us who the patients are and how much care they need. Many scheduling systems don't actually attempt to connect to the EMR- but the best ones need to, and moving the needle on labor efficiency is difficult without the demand side. Just as it would be challenging to schedule the right amount of airline pilots without knowing the number of flights, or the amount of fry cooks without knowing how many burgers are needed. Clinical scheduling is arguably even more sensitive- down a fry cook, customer waits longer for a burger. Down a nurse, patient safety is at risk. And yet, many systems operate disconnected from the EMR, with nursing leaders operating off patterns ("we usually need 6 nurses for Tuesday AM shifts") and heuristics ("Dr. Brown is in our OR this week- many complicated cases, we might need more staff").

HRIS= human resources information system. AKA payroll, time & attendance (T&A)*. Non-administrative nursing roles are hourly- they punch a clock. Scheduling needs to read, and sometimes write, into the T&A system. Scheduling without T&A is naked- you're missing a big part of the picture. Some systems bundle T&A and scheduling together- this is ideal, but many of the systems that do it aren't "Smart" or connected to the EMR (see above). Standalone systems, like the one made by In-House Health, attempt to deliver more flexibility, automaticity, and ROI, which is exactly why we treat the HRIS integration as core product and not a services afterthought. Get it wrong and you frustrate Finance, Nursing and HR/Payroll all at once.

In skilled nursing the stakes are even higher than "the schedule looks off". For Nursing Homes, the CMS Payroll-Based Journal (PBJ) reporting means scheduled hours, punched hours and reported hours all need to tie out, and that staffing data feeds your star rating. A broken HRIS connection isn't just annoying, it's a regulatory and reputational problem. In many regions, state regulations, union agreements have certain requirements that require validation in the time clock (meal breaks, staffing ratios on the floor).

And 2 is the minimum. Depending on the org, additional ADT feeds outside of the one provided by the EMR (admits, discharges, transfers), acuity tools, credentialing and license verification, agency marketplaces, paging/communication tools, and so on.

Both of these systems are incredibly complex at their core- they change data mappings and definitions, sometimes for system-driven reasons (the EMR changes a billing process, which alters medical coding upstream), or for organization-driven reasons (the provider introduces a new type of employee bonus pay, which changes pay coding in the HRIS). That's the whole point. You don't build an integration once. You build it, and then the ground changes underneath it.

It gets worse when you look at how the data actually moves. A lot of "integrations" in healthcare aren't slick real-time APIs, they're a flat file dropped on an SFTP server every night. So your view of the world can be up to 24 hours old, in a building where census changes by the hour. Then there's who owns what. HRIS owns the employee, EMR owns the patient, scheduling owns the shift. Things break when 2 systems both think they own the same thing (whose version of her home unit is right?). Then there's matching people across systems- same nurse, 3 different IDs, and agency/PRN staff who don't exist in the HRIS at all. And just getting access can be a project. EMR vendors may charge for API access or require marketplace approval.

Remember our friends from part 2 whose day starts at 11pm? Their schedule day starts at 11pm, but their payroll day starts at midnight and their pay week starts Sunday. Now a night shift's hours belong to different days depending on which system you ask. OT gets calculated on one boundary and forecast on another. This is what I meant in part 1 about the interactions. Configurability is hard, integration is hard, configurability on top of integration is where it really breaks.

And the scariest breakage isn't the loud one. If the sync fails and someone gets an alert, that's annoying but fine, someone fixes it. The scary one is when everything keeps "working" on bad data. The schedule looks normal, the app still gets 5 stars, but the census is 3 days stale or a pay code is quietly getting dropped, and your staffing recommendations are wrong in ways nobody can see until it shows up in OT, or worse, on the floor.

Where does AI come in? AI does help - from scoping & developing net new integrations that build on the methods of the rest of the system, to error detection and response, to imputation of omitted data, there are many ways that LLM-driven supports of standard APIs makes this better. Some real examples: an agent notices hours for 2 West dropped 40% overnight and flags it as a likely mapping change, not reality. A new pay code shows up in the payroll export, and an LLM reads it and proposes where it maps, for a human to approve. A punch is missing, and the system suggests what probably happened and flags it. It doesn't quietly fill it in, because that's wage & hour territory and nobody wants to explain an AI-inputed paycheck to the Dept of Labor.

But it doesn't work out of the box: like a lot of enterprise-grade tech, the automations are only as good as the team that deployed the integration and the supporting tools in the first place, and can even make the problem worse if half-deployed. Picture an auto-mapper that confidently files the new retention bonus as regular hours. Now every OT number downstream is wrong, and it all looks right.

So, if you want a scheduling system that still works a year after go-live, you better build it for the ground moving, not for a snapshot of the client on implementation day. That means monitoring, alerting, mapping tools, and a team that actually knows what a pay code is.

Next up, part 4: automated and smart. Where the agents actually come in (and where they can make things worse).

* sometimes, Payroll and T&A can be separate- sometimes they're combined. For now, we'll pretend we're in the happier world where the HRIS is a single entity with everything except scheduling.

--

Common integration points for clinical scheduling

EMR / demand: Census/ADT Feed, Acuity or care-hours targets, Diagnoses, Demographics

HRIS / employees: New hires and terminations, Job codes and home unit, Pay rates, Licenses

Time & attendance: Punches and missed punches, Pay codes, OT and premium pay rules, Pay period boundaries

Third party: Labor marketplaces

‍