Home › Learn

Is asset tracking data covered by HIPAA?

By Thaddeus Stepanovich — Founder, Harbinge.rs · 14 years in EMS and healthcare IT

When does asset data become PHI-adjacent?

On its face, an asset record is not health information. A tag number, a device model, a room assignment, and a last-serviced date describe a piece of equipment, not a patient. HIPAA's definition of protected health information (PHI) is individually identifiable health information — data that relates to a person's health, health care, or payment for health care, and that either identifies the individual or could reasonably be used to identify them. A record that says "Infusion Pump #4471 — Room 6-C" doesn't meet that bar by itself.

The gap between "not PHI" and "PHI-adjacent" closes fast once context is added. A location history that tracks a specific pump moving into a specific patient room and staying there for the duration of a stay is, in combination with other records, a proxy for that patient's admission, room assignment, and length of stay. An incident investigation is the clearest example: when a safety team joins an asset log to a clinical event — which infusion pump was in which room during which shift when an adverse event occurred — the asset log stops being incidental equipment metadata and becomes part of the evidentiary trail around a patient encounter. The same is true for outbreak investigations, contact tracing, or any exercise that asks "which devices were near which patients, when."

Because that kind of join is difficult to rule out in advance — a security or compliance team can't always predict every future report a colleague might run — the safer assumption for governance purposes is contextual linkability: treat location and timestamp data as capable of becoming identifying, even when the record itself contains no patient name, MRN, or diagnosis. That doesn't mean every asset tracking deployment must be run as a full PHI system. It means the design choices below should assume that possibility rather than dismiss it.

Does the tracking vendor need a BAA?

The relevant legal test isn't whether a vendor is "in healthcare" — it's whether the vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity. That's the statutory definition of a business associate, and it's a functional test, not an industry label. A payroll processor that never touches clinical data isn't a business associate just because its customer is a hospital. A software vendor that never touches patient-identifiable information in the course of providing its service isn't automatically one either, purely by virtue of operating inside a hospital's network.

Where this gets tested in practice is exactly the contextual-linkability scenario above: if a tracking vendor's system, database, or support process could expose data that's linkable to a patient — even indirectly, even rarely — a covered entity's compliance and legal teams will treat that as PHI exposure risk and require a Business Associate Agreement (BAA) before deployment. This is the correct default position for a covered entity to take, and a well-run vendor should expect it and be ready with a signed BAA rather than treating the request as a negotiation. Vendors that push back on a BAA request, or that can't clearly describe what data their system touches, are handing a security review an easy reason to say no.

The practical takeaway for a security team evaluating a vendor: don't accept "we're not really a healthcare product" as an answer to the BAA question. Ask what the system stores, whether that data could ever be joined to a patient identity, and whether the vendor has a BAA ready to sign. If the answer to the first question is ambiguous, the answer to the third should be yes anyway.

What architecture choices reduce exposure?

Because the goal is to minimize the surface area for a PHI-adjacency argument to ever arise, the architecture choices that matter most are the ones that remove identifying detail before it's ever stored, not the ones that add controls after the fact.

• Hash device identifiers before storage. Raw MAC addresses and other hardware identifiers should never be retained in plain form. Hashing them at the point of capture means that even if a location database were exposed, it wouldn't yield a reversible map of specific physical devices to specific network identities.
• Enforce strict tenant isolation at the database layer. In any multi-tenant system, isolation should be a database-level guarantee — enforced by the schema and query layer itself — not an assumption baked into application code that a bug could quietly violate. This matters even for organizations with a single facility, because it's the same architectural discipline that prevents a support engineer's mistake from becoming a cross-tenant data exposure.
• Avoid free-text fields that invite PHI entry. A "notes" field on an asset record is an open door: a well-meaning technician will eventually type a patient's name or condition into it because it was the fastest place to leave a note. Structured fields with defined vocabularies close that door by design, rather than relying on a policy telling staff not to do it.
• Log every administrative access. An audit trail that records who viewed or exported location data, and when, doesn't prevent an incident — but it's the difference between being able to answer "who had access to what" during a security review and not being able to answer it at all.

None of these choices require a system to formally become a HIPAA-regulated PHI repository. They're the same hygiene a well-run security program applies to any sensitive operational data, applied here because the downside of skipping them — an unresolvable "was this PHI" argument during an incident review — is disproportionate to the cost of doing them from the start.

What should security review ask an asset-tracking vendor?

A hospital security or compliance team evaluating an asset tracking vendor is, in effect, running a scaled-down version of the same review it would run on any system touching its network. The questions worth asking are concrete and answerable, not abstract compliance-posture questions:

• Identifier handling. Are raw device identifiers (MAC addresses, serial numbers) ever stored in plain form, or are they hashed or tokenized before storage? Can the vendor reverse a hash back to a raw identifier, and under what circumstances?
• Tenant isolation mechanism. Is isolation enforced at the database layer, or only in application logic? What happens if a query is malformed — does it fail closed or could it leak across tenants?
• Breach notification terms. What does the vendor's contract commit to in terms of notification timeline and scope if an exposure occurs, and does that commitment match or exceed what the covered entity's own breach-notification obligations require of it downstream?
• Data residency. Where is data stored and processed, and does that location satisfy the covered entity's own policy and any state-level requirements that apply to it?
• Subprocessors. Which third parties does the vendor rely on — cloud hosting, analytics, support tooling — and do those subprocessors have their own BAAs in place where relevant?
• Export and deletion. Can the covered entity export its own data on demand, and does the vendor have a defined process for deleting data on contract termination, including from backups?

A vendor that can answer all six clearly, in writing, without hedging, has almost certainly already done the architectural work described above. A vendor that can't is asking the covered entity to take the risk on faith — which is a bad trade for a system with no clinical function of its own.

Where Forager fits

Forager is HIPAA-ready by design, and a Business Associate Agreement (BAA) is available. That's a direct answer to the vendor-evaluation questions above, not a marketing claim layered on top of them: MAC addresses are hashed before storage, so raw device identifiers are never retained; Row-Level Security enforces tenant isolation at the database layer, so no organization's data is reachable from another's; no personally identifiable information is collected beyond the asset records an organization explicitly defines; and every confirmation carries a full audit trail — who confirmed it, when, and where. See the full FAQ on Forager's security architecture for the underlying detail.

That architecture was a starting assumption, not a retrofit, because Forager's target customers are hospitals, health systems, and biomedical/facilities teams operating in exactly the PHI-adjacent territory this article describes — networks where an asset tracking system sits alongside clinical systems and where "could this ever be linked to a patient" is the question every security review eventually asks. See how Forager works for the mechanics of how location confirmation happens without adding infrastructure or expanding what data gets collected.

None of this substitutes for a covered entity's own risk analysis or its own counsel's read on where a specific deployment sits relative to its HIPAA obligations — that determination depends on facility-specific facts a vendor can't make on a customer's behalf. What Forager can offer going into that review is an architecture built to make the answer as clean as possible: minimal identifiers, isolated tenants, and a complete record of who accessed what.