Every risk analysis rests on a list of where the ePHI is, and in a hospital that list is the part most likely to be wrong. The EMR is on it. The pharmacy dispensing cabinets, the ultrasound that caches studies on a local drive, the fax server, and the departmental database somebody built in 2014 are frequently not. A system missing from the inventory does not fail the assessment. It scores nothing at all, which looks exactly like scoring clean.
The requirement nobody quotes
The Security Rule never says asset inventory. The obligation arrives through the back door, and OCR's Guidance on Risk Analysis states it plainly under its Data Collection heading:
Must identify. Must be documented. The guidance also sets the outer edge of the scope, and it is deliberately wide: the analysis covers all ePHI an organization creates, receives, maintains, or transmits, “regardless of the particular electronic medium in which it is created, received, maintained or transmitted or the source or location of its e-PHI,” and electronic media “includes a single workstation as well as complex networks connected between multiple locations.”
That is the whole basis for the inventory. It is not a best practice borrowed from a framework. It is the first step of a Required implementation specification, and everything downstream inherits its errors.
Why a missing system scores clean
Consider the arithmetic of a risk analysis. You identify systems holding ePHI. You identify threats and vulnerabilities against them. You rate likelihood and impact. You assign risk levels and produce corrective actions.
Now drop a system from step one. It has no threats identified against it, so it generates no vulnerabilities, so it receives no likelihood or impact rating, so it contributes no risk, so it produces no corrective action. It does not appear in the report as a gap. It does not appear in the report at all. The analysis comes back with a lower risk score than the hospital deserves, and the number moved in the reassuring direction.
This is the property that makes inventory errors worse than assessment errors. A badly assessed system is visible: it is in the report with a wrong rating, and someone can argue with it. An uninventoried system is invisible, and its absence is indistinguishable from safety. The report is not lying. It answered the question it was asked, about the systems it was given.
Beyond the EMR, in ONC's own words
ONC's overview material for the free federal assessment tool makes the point in one line, and it is worth repeating to anyone who thinks the EMR is the assessment:
The same material warns that a questionnaire answered narrowly produces a narrow result: organizations “should take care that its responses reflect an accurate and thorough assessment of the questions presented and are not merely a clerical exercise to produce a report,” and “responding to questions without considering how the questions apply throughout the organization may result in a risk analysis that is not accurate and thorough as required by the HIPAA Security Rule.” Its blunt summary: “the value of the SRA to your organization depends on the integrity of the input.”
That is the government describing the failure mode of its own free questionnaire. The questions are fine. The scope you bring to them decides what the answers are worth.
Where the ePHI is
A hospital inventory that stops at systems IT provisions will be short by a wide margin. The recurring omissions cluster:
| Category | Systems that hold or move ePHI |
|---|---|
| Clinical, outside the EMR | PACS and imaging modalities, LIS and analyzer interfaces, pharmacy and dispensing, anesthesia records, telemetry and ECG management, endoscopy and ultrasound reporting, dictation and transcription |
| Departmental | The Access database in cardiology, the shared drive in quality, the registry export in oncology, the spreadsheet the OR uses for scheduling |
| Communications | Email, fax servers and e-fax services, secure messaging, on-call paging, the answering service |
| Administrative | Registration, billing and coding, denials management, release of information, patient kiosks and check-in tablets |
| Storage and transport | Backup targets, archives from the previous EMR, imaging archives, portable drives, the retired server nobody decommissioned |
| Vendor-hosted | Cloud applications, remote-hosted departmental systems, vendor support tunnels into clinical equipment |
| Legacy | The read-only instance of the system you migrated off, still running because someone might need a 2016 chart |
The legacy row deserves its own note. Migrations rarely delete anything. The old system gets set to read-only, moved to a corner, and dropped off the patch schedule while retaining every record it ever held. It is often the single largest concentration of ePHI in the building and the least maintained. It belongs in the inventory precisely because nobody thinks about it.
The biomedical estate, and why it is missing
Connected medical equipment is the most consistent gap, and the reason is organizational rather than technical.
Infusion pumps, patient monitors, ventilators, imaging modalities, and diagnostic carts routinely store patient identifiers and study data locally, and transmit it across the network. They are also usually owned by clinical engineering, maintained under a service contract, and patched on the manufacturer's schedule rather than yours. So they do not appear in the IT asset database, because they were never IT assets. They appear in a different spreadsheet, kept by a different department, for a different purpose.
None of that narrows the scope. The ePHI is held by the covered entity regardless of which cost center owns the device or which vendor services it. The practical move is simple and rarely done: ask clinical engineering for their equipment list, and reconcile it against the IT inventory. The delta is usually large, and it is usually the most interesting document produced by the entire assessment.
Vendor remote access is worth capturing on the same pass. Equipment that phones home, or that a manufacturer dials into for support, is a path into the network and to the data. That path belongs on the inventory as an attribute of the device.
The inventory is also a physical safeguards document
An asset inventory reads like a technical artifact and does double duty as a physical one. 45 CFR 164.310(d)(1) sets the device and media controls standard:
Its accountability specification at 164.310(d)(2)(iii) asks you to “maintain a record of the movements of hardware and electronic media and any person responsible therefore,” and two of its specifications are Required rather than Addressable: disposal at 164.310(d)(2)(i), and media re-use at 164.310(d)(2)(ii), which requires removal of ePHI from media before the media are made available for re-use.
You cannot control the movement of hardware you never listed, and you cannot evidence the final disposition of a drive you did not know existed. Which is the argument for building the inventory by walking rather than by querying. A query returns the devices that are on the network today and answering. It does not return the drive in the drawer, the tapes in the cabinet, or the laptop in a locker since the person left. Those are 164.310(d) items, they are the ones that turn up in breach reports, and the only tool that finds them is a person opening the drawer.
Three ways to find what nobody documented
OCR's guidance contemplates several data gathering methods, including “reviewing past and/or existing projects,” “performing interviews,” and “reviewing documentation.” In practice three angles surface most of what is hiding:
- Follow the money. Accounts payable knows every vendor being paid. Some of them are running a system nobody registered, bought by a department with a credit card. The AP ledger is an unusually honest inventory of your software estate.
- Follow the network. DHCP leases, switch port mappings, and certificate inventories list hosts that exist. Reconciling them against the systems anyone will claim produces a short list of things worth walking to.
- Follow the work. Ask each department what they do when the main system is down. The answer names the shadow system, the local spreadsheet, or the paper-then-scan workflow that keeps them running, and those workarounds hold ePHI by definition.
That third question is the highest-yield one in the whole exercise, and the reason is that it does not assume the answer. “Do you have any systems with patient data?” gets a no from a department manager who does not think of her tracking spreadsheet as a system. “What do you do when the EMR is down?” gets the spreadsheet, described in detail, with pride.
What each row needs to carry
A list of system names is not an inventory a risk analysis can use. Each entry earns its place by carrying the attributes the later steps consume:
- What ePHI it holds, and roughly how much. A system with 40 records and one with 400,000 do not carry the same impact rating.
- Where it physically lives. Which room, which building, which site. This is the column that makes 164.310 assessable and multi-site scope real.
- Who owns it and who supports it. The department, and the vendor if there is one, including whether a business associate agreement exists.
- How it is reached. On the network, isolated, cloud-hosted, or accessed through a vendor tunnel.
- Its lifecycle state. Live, legacy read-only, or awaiting disposal. The last one connects the row to the Required disposal specification.
Fill those in and the threat identification step becomes mechanical. Leave them out and the assessment is rating the name of a system rather than the system.
Keeping it true
An inventory is accurate on the day it is built and starts decaying immediately. The rule's own maintenance triggers are change-based rather than calendar-based: 45 CFR 164.306(e) requires review and modification of security measures as needed, and 164.316(b)(2)(iii) requires documentation to be reviewed periodically and updated as needed in response to environmental or operational changes. OCR's guidance is explicit that “the Security Rule does not specify how frequently to perform risk analysis,” and describes the integrated version as one performed “as new technologies and business operations are planned.”
The version of that which survives contact with a hospital is unglamorous: hang the inventory update on processes that already exist. Procurement, project intake, and change control are the three places new ePHI enters the building, and a system that gets added to the inventory when it is purchased never has to be discovered later. Discovery is the expensive path, and it is the one you take when intake does not exist.
One forward-looking note. Updates to the Security Rule have been proposed and have not been finalized. Proposed requirements are not binding, and nothing in this article depends on them. The requirement to identify and document where ePHI lives is current law today, through 164.308(a)(1)(ii)(A) and 164.316(b)(1).
Common questions
Does a HIPAA risk analysis need an asset inventory?
The Security Rule does not use the phrase asset inventory, and OCR's Guidance on Risk Analysis makes the requirement unavoidable anyway. Under Data Collection it states that an organization must identify where the e-PHI is stored, received, maintained or transmitted, and that the data gathered must be documented, citing 45 CFR 164.308(a)(1)(ii)(A) and 164.316(b)(1). Every later step depends on that list. Threats are identified against systems, likelihood and impact are rated per system, and risk levels are assigned per pairing. A system missing from the inventory is a system with no threats, no rating, and no risk, which reads as a clean result rather than an absent one. That is why an incomplete inventory is more dangerous than an incomplete assessment.
Do medical devices belong in a HIPAA risk analysis?
If they create, receive, maintain, or transmit ePHI, yes. The scope in OCR's guidance covers all ePHI regardless of the particular electronic medium in which it is created, received, maintained or transmitted or the source or location of that ePHI, and it names hard drives and other storage devices among the forms of electronic media. Infusion pumps, monitors, ECG carts, ultrasound units, and imaging modalities frequently store studies or patient identifiers locally. The complication is organizational rather than regulatory: these devices are usually managed by clinical engineering or a service contract rather than IT, so they are absent from the IT inventory the assessment is built from. Ownership of the device does not change scope. The ePHI is held by the covered entity either way.
Is an EMR-only risk analysis enough for HIPAA?
No. 45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to the ePHI held by the covered entity, not to a designated system. OCR's guidance states the scope covers all ePHI an organization creates, receives, maintains, or transmits. ONC's overview material for the federal assessment tool puts the practical version directly: regarding applications, be sure to look beyond just the EHR system, listing practice management, scheduling, billing, telecommunications, e-mail, and cloud apps as platforms that can contain or access ePHI. An EMR-scoped analysis is a legitimate piece of work. It is a component of a risk analysis, not the whole one.
How do you find ePHI nobody has documented?
Three sources tend to surface what the IT inventory missed. Follow the money: accounts payable lists every vendor being paid, including the ones with a system nobody registered. Follow the network: DHCP leases, switch port mappings, and certificate inventories show hosts that no one has claimed. Follow the work: ask each department what they do when the main system is unavailable, because the answer names the shadow system, the spreadsheet, or the local drive that keeps the department running during downtime. Interviews are explicitly contemplated by OCR's guidance, which lists performing interviews among the ways an organization could gather relevant data. The systems that matter most are the ones nobody thought to mention, so the question has to be asked in a form that does not assume the answer.