HIPAA Technical Safeguards for PACS and Interface Teams: What Each Control Means in Practice

The HIPAA Security Rule is written to be technology-neutral, which is why it survives decades of infrastructure change — and why it is frustrating to implement. It tells you to implement access controls; it does not tell you what that means for a PACS with fourteen modalities and a teleradiology partner.

This is a working translation of the technical safeguards into decisions an imaging or interface team actually makes. It is not legal advice, and your compliance office remains the authority for your organisation. The engineering content should be useful regardless of jurisdiction — the control set maps closely onto GDPR's technical and organisational measures and onto ISO 27001, and the last section covers that mapping.

First: "Addressable" Does Not Mean Optional

This is the most consequential misunderstanding in the whole rule.

Implementation specifications come in two kinds. Required means implement it. Addressable means assess whether it is reasonable and appropriate for your environment, and then do one of three things:

Implement it, or
Implement an equivalent alternative measure that achieves the objective, or
Document why neither is reasonable and appropriate

Option three is legitimate and is the one that gets misused. What makes it defensible is the documentation — a recorded analysis showing you evaluated it, considered the alternatives, and reached a reasoned decision. What makes it indefensible is silence.

In practice, if an addressable specification is widely implemented across the industry and your organisation has not implemented it and cannot show the analysis, that is a finding. Encryption is the obvious example: it is addressable, and choosing not to encrypt without a documented rationale is a difficult position to defend today.

Access Control

The objective: technical policies and procedures that allow access to systems holding electronic PHI only to those granted rights.

For imaging and interface environments:

Unique user identification (required). Every person accessing a clinical system has their own account. The recurring violations are shared workstation logins in radiology and shared vendor support accounts. Both are common, both are findings, and both destroy the audit trail everything else depends on — if three technologists share a login, no audit log can attribute an action to a person.

Emergency access procedure (required). A documented way to reach ePHI during an emergency when normal access paths are unavailable. This overlaps with your downtime procedures, and the two should be written together. A break-glass mechanism that is technically present but undocumented does not satisfy this.

Automatic logoff (addressable). Session termination after inactivity. The clinical tension is real: a reading station that logs off during a dictation is a safety and adoption problem. The workable answer is context-sensitive timeouts — short on shared ward workstations, longer on physically secured reading rooms, with the reasoning documented. That documented reasoning is what makes a longer timeout defensible.

Encryption and decryption (addressable). Covered below.

Audit Controls

The objective: hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI.

This is a required standard with no implementation specifications, which means you must have audit controls but the rule does not dictate their form.

For imaging systems, the practical minimum is a record of who accessed which patient's studies, when, from where, and what they did. Most PACS and RIS platforms can produce this. The questions that determine whether it satisfies the standard:

Is it enabled? Audit logging is sometimes off by default for performance reasons.
Is it retained long enough to support an investigation? Intrusions and inappropriate-access cases are routinely discovered months later.
Is it protected from modification by the people it records — which means forwarding it off the originating host.
Is it examined? The rule says record and examine. Logs nobody reviews are an incomplete control, and "we have logs" is a weaker answer than "here is the exception report we run weekly and the investigation it triggered in March."

Integrity

The objective: protect ePHI from improper alteration or destruction.

Imaging has a specific integrity concern that general IT guidance does not address: the binding between images and the patient they belong to. A study attached to the wrong patient is an integrity failure with direct clinical consequences, and it is far more likely to arise from a demographics mismatch or a bad merge than from an attacker.

Controls that matter here:

Reconciliation between RIS/HIS demographics and DICOM headers, with exception handling for mismatches
Controlled, audited procedures for merges, corrections, and study reassignment
Checksums or equivalent verification on archive migration and tier movement
Immutable archive copies, which serve integrity as well as resilience

Mechanism to authenticate ePHI (addressable) — a means of confirming data has not been altered or destroyed without authorisation. Checksum verification on archive and migration paths is the usual practical implementation.

Person or Entity Authentication

The objective: verify that a person or entity seeking access is who they claim to be. Required, with no separate implementation specifications.

For imaging environments, the item deserving attention is machine-to-machine authentication. A DICOM AE title is not authentication. It is an unauthenticated string, and any device that can reach the port can assert any value. AE title allow-listing is a useful configuration control and should not be represented in compliance documentation as authentication of the peer.

Where genuine peer authentication is needed — external connections, cross-segment paths, teleradiology partners — mutual TLS provides it. Where the equipment cannot support it, the compensating control is network isolation, and that substitution belongs in the documented analysis.

For human authentication: multi-factor on remote and administrative access is now the baseline expectation, and its absence is difficult to defend in an assessment.

Transmission Security

The objective: guard against unauthorised access to ePHI transmitted over a network.

Integrity controls (addressable) — ensure transmitted ePHI is not improperly modified in transit.

Encryption (addressable) — encrypt in transit where reasonable and appropriate.

The imaging reality is that a great deal of DICOM and HL7 traffic still moves unencrypted inside hospital networks. The defensible position depends on where the traffic goes:

Path	Expectation
Crossing the internet or any third-party network	Encryption, effectively without exception
Between sites over private circuits	Encryption expected; document any exception
Between segments within a hospital	Encryption preferred; segmentation may be a reasonable alternative if documented
Device that cannot support TLS	Documented analysis, compensating controls, entry on the risk register

The final row is where most environments actually live. What makes it defensible is that the analysis exists, the compensating controls are real and verified, and the gap is tracked with an owner rather than forgotten.

Encryption: Worth More Than the Control

Encryption appears twice as an addressable specification, and it carries a benefit beyond the safeguard itself.

Under the Breach Notification Rule, PHI that has been rendered unusable, unreadable, or indecipherable to unauthorised individuals — following the methods identified in HHS guidance — is not subject to breach notification if it is lost or stolen. A properly encrypted stolen laptop or backup tape is an incident to investigate; an unencrypted one is potentially a notifiable breach with all the cost and reputational consequence that follows.

That asymmetry is usually the most persuasive argument available when funding encryption work, because it converts a compliance control into avoided cost that leadership can size.

Encryption at rest is worth applying to: image archives including cloud tiers, clinical databases, backup media and repositories, interface engine logs and message journals (which routinely contain full PHI-bearing messages), and any workstation that caches studies locally.

That interface-log item is regularly missed. Engines log complete HL7 messages for troubleshooting, so the log directory holds identifiable clinical data — frequently protected far more weakly than the systems that produced it.

The Documentation That Proves It

The rule requires policies and procedures to be documented, retained for six years from creation or last effective date, and reviewed periodically. In an assessment, documentation is the difference between a control you have and a control you can demonstrate.

What is worth maintaining for the technical safeguards specifically:

Risk analysis covering imaging and interface systems by name, with the technical safeguard decisions traced back to it
The addressable-specification analysis — for each one: implemented, alternative implemented, or not reasonable, with reasoning and a date
System inventory identifying which systems create, receive, maintain, or transmit ePHI
A data flow map showing where ePHI moves, including external transmissions
Access review records with dates and outcomes
Audit log review records — evidence the examination requirement is met
Configuration evidence: encryption status per path, authentication configuration, retention settings
Business associate agreements for every vendor touching ePHI

The data flow map is the most useful artefact on that list operationally as well as for compliance. Teams frequently discover flows they had forgotten while drawing it — a research export, a legacy interface, a departmental database pulling directly from production.

For Non-US Teams

The engineering controls transfer directly even where HIPAA does not apply.

GDPR Article 32 requires appropriate technical and organisational measures, explicitly naming encryption, pseudonymisation, confidentiality, integrity, availability, resilience, and regular testing of effectiveness. Every control above maps onto it.
ISO 27001 / 27002 covers the same ground with a broader control set, and its Annex A structure is a reasonable framework for organising the evidence.
National health-sector frameworks — the UK's DSPT, Australia's My Health Record framework, and others — are largely restatements of the same technical expectations with local reporting obligations layered on.

If you build to the control set above and document the decisions, satisfying the local framework becomes a mapping exercise rather than a new programme.