As home-based and visiting care expands, devices carrying clinical information increasingly leave the building. A tablet opens a chart at a patient's home; notes are entered on a laptop between visits; an on-call clinician connects from home. This is operationally necessary — stopping it is not an option.
Endpoints are also the area where control reaches least. Unlike servers and network equipment, devices physically leave your hands. They get left behind, stolen, mixed up with personal property, or simply stay with a member of staff long after they stopped being used. Few hospitals can state which devices exist, where each is now, and what is on it.
This article covers how to handle mobile and personal devices, what must be possible when one goes missing, and how to connect endpoint management to the asset register.
Disclaimer: This is general information. Guideline interpretation, personal data law, and reimbursement requirements are governed by ministry publications and regional health bureau notices.
What Changes When a Device Leaves
| Concern | In-house | Taken off site |
|---|---|---|
| Physical control | Locks and access control protect it | They do not. Loss and theft are real threats |
| Network | Managed networks only | Home, public Wi-Fi, mobile |
| Users | Staff only | Family members may handle it |
| Updates | Managed centrally | Updates never arrive unless it connects |
| Visibility | Continuous | Unknown while out of hand |
| Disposal | Follows internal procedure | May never be returned |
The first row matters most. In-house security silently assumes physical control — that only certain people can enter the building. The moment a device leaves, that assumption disappears, and it must be replaced by controls that do not depend on it: encryption, authentication, remote management.
The fourth row is equally easy to miss. A device that stays off the network for months never receives OS or software updates, and "only the mobile devices are months out of date" happens readily.
For device selection and workflow in home-based care, see Tablets and Mobile EMR for Home Care; this article covers its security side.
What a Mobile Device Needs
Two things need protecting: the information stored on the device, and the internal systems reachable through it.
| Measure | Purpose | Priority |
|---|---|---|
| Full-disk encryption | Makes contents unreadable once out of your hands | Highest |
| Strong device login | Makes a found device unusable | Highest |
| Designing so no data is held locally | Shrinks the consequence itself | High |
| Remote lock and wipe | Allows invalidation after loss | High |
| Short auto-lock | Reduces exposure when left unattended | High |
| Update status visibility | Prevents stale devices staying in use | High |
| Anti-malware | General threat coverage | Medium |
| Removable media restrictions | Limits exfiltration through the device | Medium |
| Privacy screens | Exposure at visits and on public transport | Medium |
Designing so no data is held locally is the highest-value policy. Use the device as a viewer with real data held internally or in the cloud, and a lost device contains no stored clinical information. Encryption and remote wipe are insurance; if there is no data, the insurance is not needed.
Connectivity at patient homes can be unreliable, so a fully online model is not always possible. Then the workable design is to hold the minimum offline (only the day's scheduled visits, say) and delete it automatically after synchronisation.
Do not over-rely on remote lock and wipe: it does nothing if the device is powered off, out of coverage, or already wiped. Encryption is the first line of defence; remote wipe is supplementary.
See Multi-Factor Authentication and Managing VPN Device Vulnerabilities.
Personal Devices (BYOD)
In hospitals, personal device use tends to sit in the state of "not permitted, but happening anyway" — on-call contact, checking rotas, work chat, often on a personal phone.
The MHLW cybersecurity checklist for healthcare institutions, published on 14 May 2025 with an accompanying manual, is more concrete and practical than earlier material and adds coverage of cloud environments, BCP, IoT and BYOD. With BYOD named explicitly, the direction of travel is toward deciding and documenting a position rather than leaving it at "not permitted." See How to Use the MHLW Checklist.
| Policy | What it means | What it requires |
|---|---|---|
| Prohibit | No personal devices for work | Presupposes issuing work devices, and a means of making the ban real |
| Permit narrowly | Permitted for defined uses only | Written scope of uses, apps and data; agreed management |
| Permit under management | Permitted with work data separated | Deployment and running costs; clarity on intrusion into personal property |
The worst state is "prohibited but tolerated." Because policy forbids it, nothing is managed or trained, yet clinical information sits on personal devices in practice — and losses go unreported. That is riskier than permitting narrowly and managing it.
If permitting narrowly, document: the permitted uses; the permitted applications; what may be stored (as a rule, no clinical information); required settings (screen lock, OS updates, loss reporting); where and how to report a loss; what happens on leaving; and what the hospital can and cannot do to a personal device. That last point materially improves staff cooperation.
What Must Be Possible When a Device Is Lost
| Information | Why | Prepare in advance |
|---|---|---|
| Which device | To target remote action | Asset number and serial in the register |
| Who held it | For fact-finding | Issue records |
| What was stored | To judge the scope of exposure | Pre-defined storage scope |
| Was it encrypted | To judge severity | Encryption status for all devices |
| Which accounts are linked | To target disabling | Device-to-account mapping |
| Last seen online | Whether remote action can work | Status from the management tool |
Whether you can answer "what was stored" decides the quality of the response. Unable to answer, you must assume the worst — patient notification, and consideration of a report to the Personal Information Protection Commission. Able to say "this device is designed to hold no clinical data, it was encrypted, and it has been remotely locked," the options widen considerably.
See Breach Reporting Obligations and Hospital Incident Response Plans.
Decide in advance: who is contacted (including nights and weekends — visiting care losses often occur out of hours); the first action the recipient takes; who establishes the facts and what they check; the criteria for judging impact; who decides whether to report; whether to notify the police; and what is recorded.
The first item is the usual bottleneck. "Contact IT" stalls whenever IT is not on duty. Put a single sheet of time-of-day contacts in the hands of everyone who carries a device.
Connecting to the Asset Register
Endpoint management decays when the register drifts from reality. Unlike fixed terminals, mobile devices are issued, returned and reassigned, so an unmaintained register diverges quickly.
| Field | Use |
|---|---|
| Asset number, model, serial | Identifying the unit |
| Holder / department | Where responsibility sits |
| Permitted off site? | Control category |
| Encrypted? | Judging impact on loss |
| OS and update status | Vulnerability response |
| Installed software | Scoping impact |
| Permitted storage scope | The first question asked after a loss |
| Under remote management? | Whether action is possible |
| Acquisition date, refresh due | Replacement planning |
| Return and disposal record | Prevents devices going untracked |
Do not skip the last row. Devices never returned by leavers, old units not collected after a swap, machines sitting in a department that nobody uses — a device whose location is unknown cannot even be noticed as lost. An annual physical reconciliation against the register removes most of this.
Maintain it as part of the wider asset register described in Segmentation and Asset Management; for disposal and media erasure see Managing USB and Removable Media.
Requirements: the Electronic Clinical Information Coordination Structure Development Addition created in the FY2026 revision requires guideline compliance and a dedicated medical information system safety management officer as common requirements, with tier 1 (160 points) adding multi-method backup with part held offline and a cyber-attack BCP with exercises. Endpoint management is unavoidable in demonstrating guideline compliance. See the FY2026 revision overview, The Three Ministries' Two Guidelines Explained, and ISO/IEC 27001 (ISMS).
Conclusion
- Once a device leaves, the implicit premise of physical control disappears and must be replaced by encryption, authentication and remote management
- The highest-value policy is holding no data on the device — use it as a viewer
- Encryption is the first line of defence; remote wipe fails on a powered-off or out-of-coverage device and is supplementary
- Mobile devices stop receiving updates; maintain visibility of their patch status
- For personal devices, "prohibited but tolerated" is the worst outcome — choose prohibit, permit narrowly, or permit under management, and write it down
- Design backwards from the moment a loss is reported — especially the ability to answer what was stored
- The register must carry permitted storage scope and return/disposal records, with an annual physical reconciliation
If you are working out mobile device rules, or balancing device choice against safe management in home-based care, contact us.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Edition 6.0 | MHLW
- Personal Information Protection Commission
- On the FY2026 Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
Note: guideline interpretation, personal data requirements and reimbursement requirements are governed by ministry publications and notices, and change with revisions.