How US health systems sync HRIS with the LMS across facilities — role-driven assignment, competency tracking, and clean staff provisioning.
Got an LMS decision on your plate?
45-minute call. Plain-English audit. Fixed-price quote if there's a fit, or a "no" if there isn't. No deck. No pitch.
The four common HRIS-LMS integration patterns, what each costs, and where most deployments quietly break — with examples for Workday, HiBob and SAP SuccessFactors.
How multi-facility healthcare providers track competencies and keep mandatory training current and audit-ready.
How SCIM provisioning automates joiners, movers, and leavers in your LMS, and why auto-deprovisioning matters most for compliance.
In most health systems, the LMS-HRIS connection carries more weight than anywhere else we work. A new RN who isn't enrolled in unit orientation on day one can't be counted toward staffing. A travel nurse whose contract ended last week but still has an active account is a survey finding waiting to happen. And a CNA who transferred from med-surg to the ED needs a different competency set the moment the transfer posts in HR — not at the next monthly upload.
Health systems run on movement: new hires, transfers, per-diem pools, agency staff, residents rotating through. The HRIS knows about every one of those events. The job of the integration is to make sure the LMS knows too, fast enough and accurately enough that training assignment, competency tracking, and account access all stay correct without anyone touching a spreadsheet.
This is a practical guide for HR and L&D leaders at multi-facility US providers who are scoping that integration — distinct from the general HRIS-LMS integration patterns and the broader healthcare staff training playbook.
Plenty of industries sync an HRIS to an LMS. A few things make healthcare harder than the generic case.
Facilities aren't departments. A multi-site system has hospitals, ambulatory clinics, surgery centers, and home-health divisions, each with its own orientation, its own compliance owner, and often its own accreditation context. Your integration has to carry facility and cost-center data, not just "department," and route training accordingly.
Roles map to credentials, not job titles. An "RN" in the HRIS is one title, but training requirements diverge by license type, unit, and scope. An OR nurse, an ICU nurse, and a float-pool nurse share a title and need overlapping but distinct competencies. The mapping is role-plus-context, and it's custom every time.
Turnover is the baseline, not the exception. Hospital RN turnover ran about 16.4% in 2024 per the NSI National Health Care Retention Report, and support and per-diem roles churn faster. An integration designed around occasional changes will drown. It has to treat hire, transfer, and termination as routine, high-volume events.
Surveyors check the record. When The Joint Commission or a state surveyor reviews competency and orientation records, the question is whether the right people completed the right training on time — and whether anyone who left still had access. The integration is what keeps that record defensible.
Strip away the vendor diagrams and a healthcare HRIS-LMS integration has four jobs.
When a hire posts in the HRIS, the LMS should create the account and enroll the person in the right orientation within minutes — not on the next nightly batch. For a nurse starting at 7 a.m., "enrolled by 7:15" and "enrolled tomorrow" are very different things when day-one compliance modules gate floor access.
The integration needs name, employee ID, facility, cost center, job code, license type, and start date. The account is keyed to the employee ID (stable) rather than name or email (both change).
This is where most generic integrations fall short. It isn't enough to put everyone in a building into one orientation. The assignment logic has to read job code plus facility plus license type and resolve to a specific training plan: HIPAA and corporate compliance for everyone, bloodborne-pathogens and unit competencies for clinical staff, controlled-substance handling for the roles that touch it.
Encode this as rules driven by HRIS fields, not as manual cohort lists someone maintains by hand. When a job code changes, the plan changes automatically.
A transfer is the event generic integrations handle worst. When a CNA moves from med-surg to the ED, three things should happen: the new unit's competencies get assigned, the old unit's now-irrelevant assignments get retired (without deleting the completed history), and the person's manager and reporting line update so the right director sees their status. A transfer that only adds and never retires leaves staff with a permanently growing, inaccurate to-do list.
When a termination or contract end posts in the HRIS, the account should be disabled promptly and access revoked — while the completion history is preserved for the audit record. This matters most for the staff who churn fastest: agency nurses, travelers, per-diem, and residents whose rotation ended. An active account for someone who left weeks ago is both a security gap and a survey finding — and in a system holding protected health information, prompt deprovisioning is part of what makes an LMS HIPAA-compliant.
The HRIS systems we see most in US health systems are Workday, UKG (Pro and the former Kronos workforce-management side), and Oracle (Fusion HCM or legacy PeopleSoft). Each shapes the integration differently.
Workday. Common in larger systems. Its data model is position-based: a person fills a position, and the position carries the job profile and cost center. Map position to required competencies, not person, so transfers resolve cleanly. The typical pattern is a Workday custom report exposed as a service endpoint (RaaS) that the LMS polls every few minutes, authenticated with a scoped Integration System User rather than a real account.
UKG. Very common in healthcare for its scheduling and time-and-attendance strength, which means facility, unit, and shift data are rich and accurate. UKG Pro has a usable REST API; the integration challenge is usually reconciling the workforce-management view of where someone works with the HR view of who they are.
Oracle. Fusion HCM exposes HCM Data Loader and REST APIs; older PeopleSoft estates lean on scheduled extracts. Position management is the norm at enterprise scale, so the same position-to-training mapping applies. Schema work tends to dominate the build.
Across all three, the principles are the same: key on stable IDs, read facility and cost center as first-class fields, drive assignment from job code plus license, and use effective-dated events so a transfer dated next Monday fires on Monday — not whenever the integration happens to run. For deeper system-by-system detail, see the HRIS integration pillar.
Healthcare L&D leaders rarely just need "did they finish the module." They need a competency record: did this nurse demonstrate the skills required for their role this cycle, validated where appropriate by a preceptor or charge nurse.
A well-built integration supports this by carrying the role and unit context into the LMS so competency assignments resolve correctly, and by feeding completion and validation data back where the system of record needs it. Done properly, the answer to "show me every ICU nurse's current competency status, by unit and manager" comes from one report instead of a reconciliation exercise across HR, the LMS, and a unit spreadsheet. That reporting capability is worth scoping explicitly — see how we approach compliance reporting.
The failure modes we see most in healthcare remediation work:
For a multi-facility US provider, a healthy HRIS-LMS integration looks like this:
None of this is exotic. It's a matter of keying on stable IDs, treating facility and credential as first-class data, encoding assignment as rules rather than manual lists, and handling the full lifecycle — including the deprovisioning step that generic integrations treat as an afterthought.
If you'd like to walk through your own HRIS, your facility footprint, and your competency model, we'll tell you what a clean integration would look like and what it would cost. We build these on platforms you own outright, so the integration is your code on your infrastructure — not a connector you rent. More detail on our approach lives on the healthcare sector page and the HRIS integration feature page.