IT for healthcare providers

Healthcare IT is usually discussed in terms of confidentiality, and confidentiality genuinely matters — medical records are among the most sensitive categories of personal data there are.

But confidentiality alone does not describe the problem. A system that perfectly protects records also prevents a clinician from reading one at the moment it is needed, and in this sector that failure has consequences no other sector's access control has.

The engineering difficulty in healthcare is holding both properties at once, and most of what is distinctive follows from it.

Access control that survives an emergency

Role-based access works for the ordinary case: a clinician sees the records of patients under their care, administrative staff see what administration requires, and nobody sees everything.

The ordinary case is not the difficult one. The difficult one is the patient who arrives unconscious, out of hours, under a clinician who has no existing relationship with them. Access control that has no answer for that will be answered anyway — by a shared login, a password written down, or an account that is never restricted because restricting it caused a problem once.

The designed answer is break-glass access: a documented, deliberate override that grants what is needed immediately and makes the use of it highly visible afterwards.

1. 1

   Grant immediately, without approval in the moment

   An override requiring someone to authorise it is an override that will not be used, and the workaround it produces is worse than the override.

2. 2

   Require a reason at the point of use

   Typed, not selected from a list. The friction is deliberate and it is the mechanism that makes casual use uncomfortable.

3. 3

   Alert on every use, in real time

   To someone whose job includes reviewing them. Unreviewed override logging is the same as no override control.

4. 4

   Review every instance, without exception

   Consistent review is what makes the control real. Reviewing some instances teaches people which ones are not reviewed.

5. 5

   Time-limit the elevated access

   It should expire rather than persist, so it does not quietly become someone's standing permission.

Designed properly, this converts the most common healthcare access failure — a shared account nobody can attribute — into an attributable, reviewable event.

Auditing access to records

In most sectors, audit logging exists for incidents. In healthcare, the routine question is different and more common: who has looked at this record?

Inappropriate access to records — by curiosity, by personal connection, by a member of staff looking up someone they know — is a recognised and recurring risk in the sector, and it is not detected by any perimeter control. It is detected only by logging reads and reviewing them.

• Log reads, not only writes. Most systems log changes and not views, and views are the exposure here.
• Retain those logs long enough to answer a question raised months later.
• Make them searchable by patient as well as by user, since the question is usually asked from the patient's side.
• Review proactively for patterns — a staff member accessing records with no care relationship, or accessing a record sharing their surname or address.
• Ensure staff know access is logged and reviewed. The deterrent works only if it is known.

The device estate that cannot be patched

Healthcare environments contain equipment that ordinary IT security advice does not fit: imaging systems, diagnostic devices, monitoring equipment and clinical systems running old operating systems because the certified configuration includes them.

This equipment frequently cannot be patched, cannot run an endpoint agent, and cannot be modified without invalidating a certification or a support agreement. Telling a provider to patch it is not advice, because they cannot.

The workable approach is to change what the device can reach rather than what runs on it.

• Put it on its own segment, with explicitly permitted flows and nothing else.
• Permit only the specific systems it must communicate with, in the specific direction required.
• Deny it general internet access unless a documented function requires it.
• Monitor its traffic, since you cannot monitor its inside.
• Record the exception, the reason, the compensating controls and a review date — so it is a decision rather than an oversight.

Availability, where downtime is clinical

In most businesses an outage is expensive. In a clinical setting an outage can affect care, which changes both the recovery target and the requirement for a documented way of working without the system.

• Recovery objectives set per system from clinical impact, not one target across the estate.
• A downtime procedure that staff have actually practised, because a procedure nobody has used is not available under pressure.
• A way to access recent critical information when the primary system is down — which frequently means a read-only copy somewhere independent.
• Backups that a compromised administrator account cannot reach, since healthcare is a known ransomware target and the encrypted-backups outcome is the one that turns an incident into a crisis.
• Restore times measured by performing a restore, not estimated.

Third parties and shared systems

Healthcare providers typically exchange data with more external parties than comparable businesses — laboratories, imaging providers, referral systems, insurers, and suppliers with remote support access into clinical systems.

• Every supplier with remote access should have individual, time-limited, logged access rather than a standing account.
• Support access should be enabled on request and disabled afterwards, not permanently available because it is convenient.
• Interfaces exchanging patient data should be inventoried, because an unknown interface is an unmonitored disclosure route.
• A supplier's access to your systems is your exposure, regardless of what their contract says about their own security.