Most health systems can’t say with confidence whether every clinical mobile device is managed and secure, and the reason is usually structure, not negligence. Devices are spread across hospitals, clinics, and affiliated sites, set up at different times by different people, and reported on in different places.
If you’re in health-system IT and someone has asked whether your clinical devices are compliant at every site, and you can only answer for some of them, this post is for you. It covers what compliant should mean for a clinical device, why visibility breaks down across sites, and how to build one view you can stand behind.
What compliant means for a clinical mobile device
Compliance needs a definition before it can be measured. For shared clinical handhelds, tablets, and phones, most health systems end up with a short list of conditions every device must meet.
| Condition | What it means in practice |
|---|---|
| Enrolled | The device is in your mobile device management (MDM) platform and checking in regularly |
| Encrypted and locked | Storage is encrypted and the device can’t be used without authentication |
| Current | The operating system and security patches are within your policy window, and the model still receives updates |
| Shared-device sign-in | Clinicians sign in and out per shift, so patient information doesn’t carry between users |
| Approved apps only | Only the clinical and communication apps the device needs are installed |
| Remotely wipeable | A lost or stolen device can be locked and wiped from the console |
Write your version down and agree it with your privacy office. The clinical mobile device management guide covers how these settings apply to common clinical workflows.
Why visibility breaks down across care sites
Health systems lose visibility for reasons that build up over years. None of them is unusual, which is why they’re hard to spot from inside.
Affiliated sites with their own setup. Clinics and partner sites often joined with their own devices, MDM tenant, or no MDM at all. Nobody decided they should be separate, but they were never brought together.
Devices configured outside IT. Some clinical devices arrive set up by a vendor for one application, and they never enter the MDM. They work, so nobody questions it.
Shared devices without shared setup. Devices passed between nurses across shifts were sometimes set up as if one person owned them. Sign-ins, cached data, and app states pile up.
Devices that stop checking in. A device in a drawer, a dead battery, or a reset device that was never re-enrolled all drop out of the console quietly.
Here’s what actually happens when a privacy review or audit asks the question. The MDM report looks healthy, then someone compares it with purchase records and finds a meaningful number of devices the console can’t see. The gap is the finding, not the devices on the report.
Why it matters under Canadian health privacy law
Clinical devices often hold or display personal health information, so device compliance is a privacy matter, not only an IT one. In Ontario, the Information and Privacy Commissioner can issue administrative monetary penalties under PHIPA of up to $50,000 for individuals and $500,000 for organizations, in effect since January 1, 2024. Other provinces have their own health privacy laws with their own requirements.
Just know that the law sets obligations, not device settings. Confirm with your privacy office and legal team what your obligations mean for device policy. The post on PHIPA compliance for mobile device management covers the Ontario requirements in more detail.
How to build one compliance view across sites
One view of compliance doesn’t require one perfect system on day one. It requires a full list of devices and a regular check of each against your definition.
- Build the full device list. Combine MDM records, purchase records, vendor lists, and site counts, including affiliated sites.
- Find the devices the console can’t see. Anything on the list but not in the MDM, or silent for 30 days, needs locating.
- Bring every device under one management setup. Enrol unmanaged devices, consolidate separate MDM tenants where you can, and retire devices you can’t bring into policy.
- Report on your definition, not the default. Build one report that checks every condition in your compliance definition, by site.
- Review exceptions weekly. Assign a named owner for non-compliant and missing devices at each site.
Some devices can’t be brought into compliance because they’re too old to run current software. One major Canadian research hospital we work with replaced aging nursing devices that had become slow and increasingly incompatible with its electronic health record system. The healthcare case study covers that replacement.
The same drift happens in every multi-site fleet. The post on why devices drift out of policy across sites covers the causes and fixes outside healthcare.
Who should own clinical device compliance
Compliance across sites needs one accountable owner. In many health systems, IT sets the MDM policy, the privacy office sets the rules, clinical units hold the devices, and nobody is responsible for the gap between them.
The owner doesn’t need to manage every device. They need the weekly exceptions report, a contact at each site who can locate devices, and the authority to remove a device from service when it can’t be brought into policy. Affiliated sites should be named in that arrangement explicitly, since they’re the most common blind spot.
Report the result to the same group that oversees privacy. When compliance is reviewed alongside privacy incidents and audit findings, it stops being an IT metric and becomes part of how the organization manages risk.
Where outside help fits
Keeping clinical devices compliant across many sites is ongoing work, and health-system IT teams are rarely staffed for it. Enrolment, policy changes, update management, and weekly exceptions compete with every other priority.
Through MDM as a Service, our certified Canadian technicians administer your MDM platform, keep policies and updates current, and work the exceptions with your team, while your organization keeps ownership of the policy and the privacy decisions. The healthcare overview covers the clinical device work we do.
Just know that it fits best for health systems with devices across several sites and a small team stretched across many systems. A single facility with a well-run MDM and a dedicated administrator may not need outside help.
Questions we hear about clinical device compliance
How do we know if our clinical mobile devices are compliant?
Define compliance first, such as enrolled, encrypted, current on updates, shared-device sign-in, approved apps, and remotely wipeable. Then compare a full device list from MDM, purchase, and site records against that definition. Devices missing from the MDM or silent for weeks are the biggest compliance gaps.
Why can’t health systems see device compliance across all sites?
Usually because affiliated sites run their own setups, some clinical devices are configured outside IT, shared devices weren’t set up for shift work, and devices drop out of the console when they stop checking in. The MDM report only covers devices it can see.
What should we fix first?
Find the devices your MDM can’t see, since they’re the biggest risk and the most likely audit finding. Locate them, then enrol, replace, or retire each one. After that, start a weekly exceptions review by site so the gap doesn’t reopen.
Where to start
Write down your definition of a compliant clinical device and agree it with your privacy office. Then compare your MDM device count with your purchase records for every site, including affiliates. The difference tells you how much of the fleet you can’t currently vouch for, and where to start. Repeat the comparison each quarter so new sites and new devices don’t reopen the gap.
References
- Information and Privacy Commissioner of Ontario, Potential consequences of a breach under PHIPA (2024). Administrative monetary penalty limits.