Ask ZDP

Both apply, but not to the same slice of the data, and the mishandling incident itself triggers HIPAA's breach notification mechanics now that the 2024 rule aligned Part 2 to them - the question is whose substantive obligations were violated.

It turns on provenance and segregation. Once your Part 2 records leave your hands with proper patient consent and land in that platform, they remain Part 2-protected in the hands of every downstream recipient who received them as Part 2 data - redisclosure restrictions and accounting-of-disclosures obligations travel with the data, not with the entity holding it. The 2024 rule did adopt HIPAA's breach notification procedures for Part 2 breaches, so the mechanics of notification are now harmonized. But that doesn't erase Part 2's own substantive rules on accounting and redisclosure, which are stricter and still distinct from HIPAA's accounting requirements. If the platform mishandles the combined dataset and can't tell which records came from you, the whole dataset may need to be treated under Part 2's more protective standard out of caution.

Before you connect, get a written data flow map from the platform showing how Part 2 records are tagged and segregated downstream, and confirm their breach response plan explicitly addresses Part 2 accounting obligations separately from HIPAA's. Don't take their BAA language on faith here.

You don't get to skip the analysis, but you also don't automatically have a reportable breach. A compromised credential is a security incident under the Security Rule no matter what, and that requires a documented risk assessment of whether ePHI was, or likely was, acquired, accessed, used, or disclosed. If that assessment concludes the risk of compromise was low, you can document that conclusion and close it out without notifying anyone. What you can't do is skip the documented assessment because IT's informal check looked clean.

This turns on how solid that evidence really is. "No unusual EHR access logged" is good, but you want to know whether logging would actually catch a quiet read-only query, whether the account had any EHR access rights at all, how far back the log review went, and whether the password was reused anywhere else. If the account had no EHR or systems access beyond basic network login, that cuts strongly toward low risk. If it had broader access and your logging is thin, that cuts the other way.

Two things to do now: have someone formally document the four-factor risk assessment under the breach notification rule, in writing, tied to this incident, not just an IT ticket. And get your risk analysis updated — it being a year stale is a separate, independent compliance gap that an auditor will flag regardless of how this incident resolves.

Yes, both of those cut against you, and yes, this is presumptively a reportable breach unless your risk assessment proves otherwise. Unencrypted PHI on a stolen device is not covered by the encryption safe harbor, so you start from the presumption of a breach under the Breach Notification Rule, and the burden is on you to show a low probability of compromise through a documented four-factor risk assessment.

The gap between theft and wipe confirmation matters because it defines your exposure window, not your notification clock. Your discovery date for the 60-day notification countdown is when the agency knew or should have known of the theft, not when the wipe confirmed. The three-day gap is a fact you weigh inside the risk assessment: who could have accessed the phone during that window, whether the passcode lock plus remote wipe capability reduced likelihood of access, and what the cached data actually contained. If the wipe confirmation shows the device never reconnected to a network before being wiped, that helps your probability analysis but does not erase the window itself.

Document the risk assessment now while the facts are fresh: passcode strength, lock screen timeout settings, wipe command issuance time versus confirmation time, and what local caching logs show about data scope. Loop in counsel before you decide whether notification is required.

No, you don't need two separate documents, but the one you keep has to actually satisfy both masters, and right now I'd bet it doesn't fully do either.

The Security Rule risk analysis is a specific, well-defined exercise: identify where ePHI lives across all eleven sites, assess threats and vulnerabilities to confidentiality, integrity, and availability, and document it in enough detail that OCR can reconstruct your reasoning. HRSA's expectation under the 330 program is broader organizational risk management tied to operational and financial risk, board oversight, and grant compliance generally. A combined document can work if the HIPAA-specific analysis is a clearly identifiable, complete component within it, not a paragraph or two referencing "cybersecurity risks." The problem I see most often with single-compliance-officer FQHCs is that the combined document is HRSA-shaped and HIPAA-thin: it talks about risk in generalities but doesn't walk site-by-site through where ePHI sits, how it moves, and what controls address each identified gap. That won't hold up under an OCR review, and this year's enforcement pattern shows OCR is specifically targeting entities with multiple locations where the risk analysis didn't actually cover every site's systems.

Pull the HIPAA risk analysis out as its own clearly labeled section or appendix, inventory ePHI location and flow per site, and map identified risks to remediation with dates. You can still fold it into the larger HRSA submission, but it needs to stand on its own if pulled out.

Your clock runs from when the subcontractor discovered the incident, not from when they told you. Under the breach notification rule, discovery is imputed up the chain: a subcontractor's knowledge is treated as your knowledge as the business associate, and your knowledge is treated as the hospital's knowledge as covered entity. The subcontractor's three-week delay in telling you doesn't toll your 60-day obligation to the hospital, it just compresses the time you actually have to work with.

What could change this is the exact discovery date versus the date the subcontractor should have discovered it through reasonable diligence, since the rule uses an objective discovery standard, not just actual knowledge. If there's a credible argument the subcontractor itself couldn't reasonably have known sooner, that matters, but a terminated employee downloading data to a personal drive is exactly the kind of thing offboarding controls are supposed to catch, so I wouldn't lean on that argument unless the facts genuinely support it.

Get a written, dated account from the subcontractor of exactly when and how they learned of this, treat your 60-day clock to the hospital as already running from that date, and notify the hospital now with what you know, supplementing as the investigation develops. Don't wait for certainty before you report.

No, withdrawing the 2021 policy statement doesn't change your disclosure analysis the way your outside counsel suggests. The policy statement was always just the FTC's interpretive gloss on what counts as "unauthorized acquisition" under the Health Breach Notification Rule - it explained the agency's view, it didn't create the obligation. The Rule itself, and its definition of breach of security, hasn't changed. The FTC's enforcement actions against companies like GoodRx and BetterHelp were built on the underlying statute and rule language, not solely on the policy statement, and those theories remain available to the agency. Unauthorized disclosure of identifiable health information to a third party you didn't intend to receive it, without proper authorization, can still trigger notification obligations even without a traditional hack.

What it actually turns on is the facts: whether the data sent through your pixels and tag manager constitutes individually identifiable health information, whether the ad platform's use of that data was authorized under your privacy notices and consents, and whether your BAAs or data processing agreements actually restrict the downstream use in a way that holds up. If the platform can use that data for its own purposes, that's a very different posture than a narrow, contractually restricted integration.

Get a technical audit of exactly what each tag is capturing before you rely on a vendor-management framing. That determination needs to happen before counsel, not after.

Your 60-day clock to the covered entity runs from your subcontractor's discovery date, not yours. HIPAA treats a business associate as having knowledge of a breach when its subcontractor (a workforce member or agent acting on its behalf) discovers it, and that knowledge imputes upward through the chain. The eleven days the coding vendor spent "confirming scope" doesn't toll anything on your end - it just eats into the time you have to notify the hospital.

This turns on two things: whether the vendor is acting as your agent under agency law (most subcontractor relationships are), and whether you can actually get the facts from them fast enough to meet your own downstream notification obligation to the hospital, which may be shorter than 60 days under your BAA with them. If the vendor is a true independent contractor with no agency relationship, the analysis is murkier, but regulators and most courts default to imputed knowledge in these setups.

Practically: get the incident timeline and scope confirmation from the vendor in writing today, and notify the hospital now even if the vendor's investigation isn't finished - you can supplement later. Separately, tighten your BAA language so "without unreasonable delay" has a number attached, like 5 or 10 days, so you're not relying on a vendor's judgment about when scope is "confirmed enough" to tell you.

Yes, almost certainly, and the fact that no appointment has been booked yet doesn't change that. HIPAA's definition of PHI doesn't require a confirmed patient relationship or a completed intake — it covers individually identifiable health information created or received by a covered entity, including information that relates to a person's health condition or the provision of care to them. If a visitor types symptoms, medication names, or "I need to see someone about my anxiety" into that chatbot before any appointment exists, that's PHI the moment it's created, and routing it to an NLP vendor for processing makes that vendor a business associate.

What it turns on is what the widget actually captures and where it goes. If the chatbot only handles scheduling logistics — name, date, time slot, no clinical content — and the vendor never touches anything health-related, you may be outside HIPAA for that specific function. But most chatbots don't stay that disciplined; visitors volunteer symptoms unprompted, and free-text fields are exactly where PHI leaks in.

Go pull the actual data flow and field-level logging for that widget before you decide anything. If there's any chance of free-text clinical input reaching the vendor, get a BAA in place now, not after an incident, and consider whether the intake form itself should be restructured to keep pre-appointment inputs strictly non-clinical.

Yes, treating email as a separate workstream from your PHI systems is exactly the gap OCR flagged in Ambry Genetics, and it stands on its own as a finding regardless of whether anything else in your risk analysis is solid. The Security Rule requires you to assess risk to ePHI wherever it lives, and email is a primary vector for both storing PHI and getting phished into a breach. An IT department's internal org chart doesn't define the scope of a risk analysis - the location and flow of ePHI does.

What it turns on is whether PHI actually moves through or rests in those email accounts, and whether phishing represents a realistic attack path into your PHI systems. If your pharmacists and staff never receive or send PHI by email and the accounts have no credential reuse or lateral access into the EHR or dispensing system, the exposure is narrower, though I'd still want that documented as a conscious, reasoned exclusion rather than an oversight. In Ambry's case, the connection was obvious and undocumented, which is what made it a standalone citation.

Go back and formally extend the risk analysis to cover email, document the decision trail either way, and get IT and compliance aligned so this isn't siloed again. Pair it with phishing-specific testing and access control review before anyone outside the building asks you for it.

Not automatically defeated, but you have a real problem to run down before you can rely on the safe harbor. The NIST-based encryption safe harbor turns on whether the data was "unusable, unreadable, or indecipherable to unauthorized individuals" - which means the key has to have actually been protected, not just the drive encrypted. If the recovery key was sitting in a spreadsheet on a shared drive, the question is who could get to that drive and whether the thief plausibly could too. If it's internal staff only, with no indication the laptop theft and the shared drive access are connected, you likely still have a defensible safe harbor position. If the shared drive was accessible remotely, poorly access-controlled, or there's any reason to think the key and the laptop could be connected by whoever took it, the safe harbor is shaky and you should treat this as a reportable breach pending your risk assessment.

This comes down to facts: who had access to that spreadsheet, how it was secured, and whether anything ties the theft to credential or network compromise rather than a random smash-and-grab. Pull the access logs on that shared drive now, and loop in counsel before you circulate any conclusion to staff, because your risk assessment and its documentation is what regulators will look at if this gets questioned later. Also fix the key storage immediately regardless of the outcome here - a password manager or your MDM's key escrow, not a spreadsheet.

No, the exclusion isn't defensible, and you should assume the vendor is a subcontractor under HIPAA. The test isn't whether the vendor's own storage layer is "de-identified" by design - it's whether they create, receive, maintain, or transmit PHI on your behalf, or on behalf of the practices whose data you host. You've already told me the answer: support agents pull up account context referencing patient names during live troubleshooting. That's PHI flowing through their system and into their agents' view, full stop. "We don't store it long-term" or "it's technically metadata" doesn't change that analysis - access and transmission trigger the obligation even without durable storage.

This turns on exactly how much patient-identifiable context actually surfaces in tickets. If support truly never sees names, MRNs, or anything tied to an individual - pure system logs, error codes, config data - you have a real argument. But you've already described the exception that swallows the rule.

Get a signed BAA with this vendor now, retroactive acknowledgment of past access if needed, and add them to your subcontractor list for all 400 practices. Also audit your ticket intake process - if agents don't need patient names to troubleshoot, scrub the field. That fixes the exposure at the source instead of arguing about it after a breach.

Your discovery as the business associate starts the clock, not each practice's own discovery date. Under the Breach Notification Rule, a BA's discovery of a breach is legally imputed to the covered entity on day one, regardless of when you get around to telling them, and HHS has been clear that covered entities can't outsource their way into a later start date through a sloppy BAA. So for all six practices, the 60-day countdown to individuals (and the covered entity's own countdown to HHS) is running now, from this week, not from whenever each practice's provider community hears about it.

What changes this is the actual BAA language, if any of the six agreements specify a shorter notification window from you to the practice, that shorter window controls and layers on top of the 60-day backstop. Also watch state law: several states have breach notification deadlines faster than 60 days, and those apply based on where the patients live, not where the practice sits.

Get written notice out to all six covered entities now, today, stating what you know and don't know, including the three where exfiltration can't be ruled out. Don't wait for forensics to finish. Silence while you investigate is the exposure that turns a vendor incident into a regulatory one.

Duration alone doesn't force notification, but your log gaps might. The safe harbor turns entirely on whether the data was rendered unusable, unreadable, or indecipherable to unauthorized persons under the NIST-based standard HHS references, which for AES-256 means the encryption process and the keys were not compromised. Eleven days of public exposure is irrelevant to that analysis if the keys stayed secure in your HSM and were never accessible alongside the data. What matters is whether you can affirmatively demonstrate the keys weren't exposed or derivable, not whether you can rule out access to the ciphertext itself.

The real exposure here is the log gap. If you cannot show, through HSM access logs, IAM logs, or key management audit trails, that the keys were never retrieved or that no process with key access touched that bucket during the window, you have a gap in your safe harbor proof, not a breach by default. That's a risk assessment problem, not an automatic notification trigger. Document what logging you do have, get your security team to characterize the gap precisely (what's missing, why, for how long), and have counsel and IT jointly assess whether the absence of evidence is itself evidence of no compromise or just poor logging hygiene. That written risk assessment, done now, is your best protection either way.

The clock runs on two tracks, and you need to move fast on both. Your own obligation as the business associate is to notify each affected covered entity without unreasonable delay and no later than 60 days from when you discovered the breach - that clock started when your log review turned up the exposure, not when you finish notifying anyone. Each covered entity then has its own 60-day obligation to notify patients and HHS, and that clock generally starts when they learn of the breach from you.

The wrinkle is agency. If any of those 12 practices could argue you were acting as their agent rather than an independent contractor - which turns on how much control they exercised over your handling of PHI, not just the label in your BAA - then their discovery is legally imputed to the date you discovered it, not the date you notify them. That compresses their 60 days to run concurrently with yours, and a late notification exposes them even if you notified promptly.

Don't wait to sort out the agency question before notifying. Document your discovery date precisely, notify all 12 practices now with full detail on scope and timeline, and flag the agency issue to each one's counsel so they can assess their own deadline conservatively.

No, the label your vendor is using does not settle the question, and the structure you describe does not obviously take you outside the Delete Act's reach.

It turns on two things. First, whether what you are licensing actually meets the statutory definition of de-identified data under California law, which is a stricter test than HIPAA's safe harbor or Part 2's de-identification standard. If reidentification is reasonably possible, especially with small behavioral health cohorts where facility, date, and service-type fields can narr

The clock starts at discovery, not confirmation - and discovery happens the moment you knew or reasonably should have known of the incident, which is typically when the portal went down and you identified it as a suspected intrusion, not when your forensic investigation later confirms PHI was actually accessed.

This trips people up every time. HIPAA's discovery standard is deliberately not tied to certainty about harm. You don't get to pause the clock while you investigate. What changes the analysis is whether you can rebut the presumption of a breach through your risk assessment - if you ultimately determine there was low probability that PHI was compromised, you may conclude no notification is required at all. But that determination has to happen within your 60 days, or informed by facts developed during that window, not used as an excuse to delay when the clock started ticking.

Two things to do now. First, document the exact date and circumstances of discovery in writing today, because that date is fixed regardless of what your investigation later shows. Second, run your risk assessment in parallel with the technical investigation, not after it, so you're positioned to notify within 60 days of discovery if the facts require it. If forensics take longer than that, you may still need to notify based on the information you have, then supplement later.

Your vendor's distinction doesn't hold up. OCR has been clear since its 2022 tracking technology guidance that the analysis isn't about which fields the pixel captures, it's about whether the data, combined with context, relates to an individual's past, present, or future health condition or care. A click on "Behavioral Health" or a URL path that reveals the same thing is exactly that kind of data, even with no name or form content attached. IP address plus timestamp plus "patient selected psychiatry appointment" is identifiable enough, and Meta's own systems are built to stitch that back to a user profile.

It turns on whether the page itself discloses condition-specific information through structure, labels, or URL, not on what the pixel technically records. If your scheduling pages separate by service line, you have a problem regardless of field-level capture. If the page is a generic "book an appointment" form with no condition context until after a login-gated, BAA-covered environment, the analysis is different and more favorable.

Two things to do now. First, get legal and technical teams to map every page where the pixel fires against what that page reveals about appointment type, and pull the pixel from anything condition-specific unless you have a signed BAA with Meta, which as of now doesn't exist. Second, treat this as a potential breach question, not just a going-forward fix, and loop in your privacy officer before deciding whether notification is triggered.

No, the vendor is wrong. Under HIPAA, the 30-day clock for a records access request starts when the request is received by the covered entity, not when it's keyed into a particular software system. If a patient emails your front desk, that email is receipt. Your vendor's intake portal may be how you prefer to process requests operationally, but it has no legal authority to redefine when the regulatory clock starts. A vendor's workflow tool cannot override a federal deadline.

What it turns on is where the request actually lands and whether that location is one HIPAA recognizes as your organization receiving it. A request sent to a front desk email, a general info@ inbox, or handed to staff in person all count as received by you, the covered entity, regardless of downstream logging. The only thing that would change this is if the request weren't validly directed to you at all, which isn't your situation here.

Practically, you need two fixes. First, put in writing, and train every site on, a same-day forwarding rule: any records request received anywhere gets logged and dated the day it arrives, not the day it hits the portal. Second, build a simple tracking log, spreadsheet is fine, that captures date of receipt independent of the vendor's system, so you have your own proof of timeliness if OCR ever asks. Don't let a vendor's software architecture become your compliance liability.

Keep implementing it. The proposed rule and its delayed timeline don't change what the current Security Rule already requires, and that current rule still obligates you to run a real risk analysis and adopt reasonable, appropriate safeguards for access to ePHI - which front-desk registration workstations touch every day. A lobbying coalition asking to withdraw a proposed rule has no legal effect on your obligations today, and proposed rulemakings get watered down or delayed far more often than they get withdrawn outright.

This turns on two things: whether your current risk analysis already identifies weak authentication at registration workstations as a gap, and whether you have a compensating control in place if you don't move to MFA now. If your last risk assessment flagged shared logins or weak passwords at those stations and you've done nothing since, you already have exposure under the existing rule, independent of anything proposed for 2027. If you have strong compensating controls - short session timeouts, no shared credentials, physical access controls - you have more room to sequence the rollout.

Don't let the 2027 date become your excuse. Pull your most recent risk analysis, confirm whether registration workstation authentication is documented as a known risk, and if it is, keep moving on remediation regardless of what happens to the proposed rule. Document your reasoning either way - that record is what protects you in an audit.

Yes, the advisory itself triggers an obligation to update your risk analysis now, not because CISA issued a bulletin, but because you now have specific, credible threat intelligence naming your sector and your exact vulnerability class as an active exploitation vector. The Security Rule requires risk analysis to reflect current threats, not just a periodic calendar. A material change in threat landscape is itself a triggering event, independent of your review cycle.

Whether delaying MFA to Q3 is defensible risk acceptance or something closer to willful neglect turns on what you do between now and then, not on the delay itself. Regulators and courts look for interim compensating controls: have you segmented those concentrators, tightened logging and alerting on them, restricted allowed source IPs, shortened session timeouts, or accelerated monitoring specifically because of this advisory? A documented decision to delay MFA with no compensating controls, made after you knew about Medusa's VPN targeting, looks like conscious disregard. The same delay with active mitigations and a clear paper trail looks like reasonable, risk-based prioritization.

Do two things this week: run and document a targeted supplemental risk analysis addressing Medusa specifically, and get your CISO to propose interim compensating controls for those twelve devices, approved in writing by someone with authority to accept residual risk. That record is what separates defensible from negligent if you get hit before Q3.

Your consultant is wrong, and confidently wrong. Encryption at rest is a security safeguard, not a substitute for the legal relationship HIPAA requires. Any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate under 45 CFR 160.103, full stop, and 164.502(e) and 164.308(b) require a BAA before that PHI starts flowing, not after go-live, not once encryption is confirmed. AES-256 might help satisfy the encryption addressable specification under the Security Rule, and it may reduce breach notification exposure if the data is encrypted per NIST standards and the key isn't compromised, but that's a completely separate question from whether a BAA is required. Nothing in HIPAA ties BAA obligations to the presence or absence of encryption.

This turns on one fact only: does the vendor touch PHI. If their platform hosts, processes, or has access to your patient data in any form, encrypted or not, they're a business associate and you need the BAA executed before any data goes near their system. There's no encryption exception anywhere in the regs.

Get this in writing from someone at the vendor with actual compliance authority, not the implementation consultant, and hold go-live until the BAA is signed. Loop in whoever owns vendor risk on your side too, because this conversation suggests their team doesn't fully understand their own obligations, which is its own red flag.

Yes, it can still count, and "no PHI yet because no login" is a weaker shield than most vendors think. HHS's position, even after the Fifth Circuit vacated part of the 2022 bulletin, is that the analysis turns on whether the information collected relates to an individual's past, present, or future health condition or care, combined with an identifier - not on whether authentication has completed. Mouse movement and scroll position on a general marketing page are unlikely to be PHI. The same data captured on a patient portal login screen, appointment scheduler, or symptom checker is a different story, because the page itself communicates something about health status or care-seeking, and IP address or device ID is enough of an identifier to make it individually identifiable.

It turns on three facts: what the page is about (portal login versus public homepage), what you can technically infer or reconstruct from field focus and timing even without capturing values, and whether you retain or could correlate that session to an identity later, including through your own logs or a shared cookie. If any of those line up, you're a business associate for that data stream regardless of the pre-login label.

Get your BAA scope and your data flow diagram in front of counsel and confirm whether your SDK fires before the covered entity's authentication boundary or your own. If it's ambiguous, treat it as PHI until proven otherwise.

Yes, most likely - and OCR's 2022 guidance is exactly why. The theory isn't that IP address alone is PHI. It's that IP/browser data combined with the fact that the person visited a scheduling page for your specific telehealth service creates an inference about a health condition or intent to seek treatment, and that combination is enough. OCR has taken the position that a page dedicated to scheduling appointments with a covered entity, visited by an identifiable individual, generates PHI even pre-login and even without a name or diagnosis field, because the individual is identified (via IP, device ID, or logged-in Facebook/Google session) and the content reveals they are seeking your services.

What changes the analysis is specificity. A general "contact us" or marketing homepage is lower risk than a page that says "Schedule your telehealth psychiatry visit" - the more the page content narrows down the type of care, the stronger the PHI argument. Whether Meta is logged in on the visitor's browser also matters; a signed-in session makes identification easier to argue.

Given where OCR and the FTC have both been active on this, I'd tell your marketing team to pull the Pixel from any scheduling-intent page now, use server-side conversion tracking with de-identified or hashed data instead, and get a signed BAA if you keep any tracking pixel on pages tied to specific services. This is a live enforcement area - don't wait for a complaint to sort it out.

Yes. The health plan is its own covered entity with its own HIPAA compliance obligations, and the hospital's risk analysis does not satisfy that requirement unless it explicitly and specifically assesses the plan's ePHI, systems, and vendors as a distinct enterprise. OCR's enforcement posture on this point has been consistent: separate EIN, separate plan documents, separate regulatory obligations, and increasingly separate scrutiny. Piggybacking on the hospital's analysis because the data happens to flow through shared infrastructure has been the exact fact pattern OCR has gone after.

It turns on how the plan's data and systems actually map onto the hospital's assessed environment. If every system touching plan ePHI, every vendor with access, and every workforce role tied to plan administration is already named and evaluated in the hospital's risk analysis with the plan's exposure called out specifically, you may be closer to compliant than you think. But if the hospital's analysis was written around hospital operations and simply happens to touch plan data as a byproduct, you have a gap, and it is the kind OCR settlements have targeted directly.

Get your privacy officer to pull the current risk analysis and identify every place the plan's PHI is named as a distinct object of assessment, not just swept in as an artifact of shared systems. Where it is silent on the plan specifically, treat that as an open finding and remediate it before OCR does it for you.

Yes. The vendor's notice three days ago is your discovery date, full stop, and your 60-day clock is already running. "Discovery" under the Breach Notification Rule is the date you knew or should have known of the incident, not the date you have confirmed scope, and not the date you have confirmed actual acquisition or viewing of PHI. Waiting for certainty before you open the file is the single most common mistake I see practices make in exactly this situation, and it's the one that turns a manageable event into a late-notification problem.

What it turns on is your business associate agreement language and the vendor's role. If the vendor is your business associate, their discovery generally imputes to you unless your BAA sets a different notice trigger to you, in which case that contractual deadline controls how fast they must tell you, but not when your own clock starts. If they're acting as more than a pass-through vendor and the incident is arguably theirs to report directly, that changes the notification mechanics but not your obligation to start your own risk assessment now.

Log it today, dated to the vendor's notice, and open a risk assessment under the four-factor standard even with unknowns, treating gaps as unfavorable to the covered entity until the vendor's forensics narrow them. Get the vendor's BAA and incident notice provisions in front of me this week.

Yes, most likely — this is a presumed breach under the HIPAA Breach Notification Rule unless you can rebut that presumption with a documented risk assessment, and "no evidence of access" alone doesn't get you there.

It turns on a few facts. First, whether that undisclosed data center is operated by a HIPAA-regulated entity or subject to comparable safeguards — if it's an unknown, unvetted facility with no BAA flowing down to it, you have unsecured PHI sitting outside any contractual or legal protection, which weighs heavily toward "breach." Second, whether the storage was encrypted to HIPAA safe harbor standards on those servers specifically. Third, whether your vendor can show the subcontractor's access controls, retention practices, and disposal met your BAA's requirements even if the location wasn't disclosed. The fourteen-month duration and nine-site scope work against you on the four-factor risk assessment — longer exposure, more records, less control all cut toward notification being required.

The BAA gap changes the vendor relationship immediately. An undisclosed subcontractor handling PHI without flow-down BAA terms is itself a compliance failure by your vendor, separate from any breach determination. Demand a written accounting of the arrangement, the subcontractor's BAA (or execute one retroactively), and audit logs. Then commission the risk assessment now, in writing, before deciding on notification — don't let the vendor make that call for you.

No, you have no independent statutory duty to verify the vendor's DROP registration or its 45-day purge compliance — that obligation runs to whoever is acting as the data broker, meaning the entity with no direct relationship to the consumer that sells personal information to third parties. Your practice treats these patients directly, so you're not a broker for this data. Your exposure is contractual, through your BAA's flow-down, warranty, and audit provisions, not a freestanding compliance duty under the Delete Act.

This turns almost entirely on whether the data your vendor is monetizing still qualifies as "personal information" under CCPA once aggregated. California's de-identification standard is stricter than HIPAA's — it requires the vendor to have technical and contractual safeguards against re-identification, and to bind its own downstream recipients the same way. If the vendor's aggregation or resale practices fall short of

That sequencing almost certainly does not hold, and the subcontractor's counsel is answering a question you didn't ask. Your duty to your forty physician group clients runs from your own BAAs with them, not from whether the subcontractor's BAA with the upstream system creates an independent obligation. Most business associate agreements define the discovery trigger as when you knew or should have known of a breach, or reasonably suspect one, not when a downstream party confirms it with certainty. If your BAAs use that "knew or should have known" standard, and most drafted in the last decade do, then a credible report of possible data involvement in a Veradigm-adjacent integration likely starts your clock now, regardless of whether the subcontractor has finished its own investigation.

It turns on your actual BAA language with each client, particularly the definition of discovery and any notification deadline, and on what you actually know today versus what's still speculative. If your agreements tie notice to "reasonable belief" rather than confirmed compromise, waiting on the subcontractor is a breach of your own contract even if HIPAA's outer deadline hasn't run yet.

Pull the BAA language for your client base now, not subcontractor by subcontractor but as a set, and get written confirmation from the subcontractor of exactly what they know and when they knew it, because that timeline will matter later regardless of who was right about the trigger.

Your notification duty runs to the practice, not to HHS. As their MSP, you're almost certainly a business associate, not a covered entity, so HIPAA's breach notification rule puts the obligation on the practice to notify HHS and affected individuals. Your job is to notify the practice without unreasonable delay, per your BAA terms, and let them make the downstream call.

What this turns on is your BAA language and the facts of the incident. Some BAAs push more onto the MSP than the regulatory floor requires, including drafting notification letters or handling HHS submission on the practice's behalf as their agent. Also check whether the registry data includes anything beyond PHI, like research data or state-specific health information, since a few states impose separate breach obligations that can attach directly to you as the entity that experienced the intrusion, independent of HIPAA's structure.

Two things to do now. First, pull the BAA for that practice and confirm exactly what "discovery" triggers and what your notification timeline and format obligations are, before you're in the middle of an incident. Second, get your incident response plan to explicitly name who calls the practice, when, and how, so nobody's improvising that call during a live breach.

Your DOT-mandated CDL collections are not governed by HIPAA's normal consent and release workflow at all - Part 40 controls the custody-and-control form, and it has its own chain-of-custody and disclosure rules that sit outside your usual intake process. This isn't a "which rule wins" conflict so much as two separate tracks: the CCF goes to the employer's designated Medical Review Officer, not through your standard release-of-records form, and the donor doesn't get to redirect or block that result the way a patient can with ordinary PHI.

The line that matters is which specimens are DOT-regulated. If this trucking client is only sending you CDL holders for federally mandated testing, those results flow through the CCF and MRO process under Part 40, full stop. If the same clinic is also doing non-DOT drug screens for that employer or others, those are ordinary employment-related tests and your normal HIPAA authorization process applies - so you'll likely be running two workflows side by side, and staff need to know which one they're in before a specimen hits the counter.

Get your collectors trained specifically on Part 40 custody-and-control procedures - this is a distinct certification, not something MAs pick up by osmosis - and have someone flag every DOT order at check-in so it never touches your regular release paperwork.

Yes, most likely — an unencrypted photo of identifiable PHI on a lost personal phone is a reportable breach unless you can show a low probability of compromise, and the fact that you never sanctioned the workflow doesn't get you out of it. HIPAA doesn't care whether the disclosure happened through an approved channel; it cares whether unsecured PHI left your control. An unauthorized workaround by your own workforce member is still your incident to manage, and depending on your Business Associate and state law obligations, "we didn't allow this" can actually hurt you, since it points to a gap in training and technical safeguards you were responsible for closing.

What changes the answer: whether the phone was passcode or biometric protected, whether it had remote wipe capability that was actually exercised, whether the photo was still on the device or had already been deleted after sending, and whether the wound photo alone (without name or other identifiers) is identifiable in context. If the phone was encrypted and locked, or you can document a timely remote wipe before any access, you may be able to document low risk and avoid notification. Absence of those facts, assume you're reporting.

Do a documented risk assessment now under your breach analysis policy, not casually. Separately, this is your signal to lock down a compliant photo/texting workflow for wound documentation before the next aide reaches for her own phone.

Yes, in most real-world configurations it does, and the fact that the patient hasn't clicked submit yet doesn't save you. If the pixel fires on page load or on field interaction and captures things like the page URL indicating a specific condition or provider, referring information, or any identifiers tied to a device or browser, you've transmitted individually identifiable health information to Meta the moment that call fires. OCR's guidance has been consistent on this point since 2022: intent to submit is irrelevant, and even an IP address combined with a visit to a telehealth intake page can be enough.

What it turns on is what data actually leaves your site and what Meta does with it. A pixel that only fires after submission, on a generic marketing page with no health context, or that you've configured to strip query strings and suppress on clinical pages is a different animal than one sitting on the intake form itself. It also matters whether Meta will sign a BAA for that data flow at all — as of my last review, they generally won't for this use case, which is why most covered entities have simply removed pixels from anything upstream of authentication or clinical content.

Get your web and marketing team to audit every page where the pixel loads, not just the intake form, and treat any page tied to scheduling, condition-specific content, or patient portals as in scope. If you can't get a BAA, pull the pixel from those pages.

Yes, you're on the hook before anything goes wrong, not just after. The Security Rule's risk analysis obligation isn't a one-time intake gate - it's continuous, and OCR has said plainly that risk analysis must be updated when there are changes to the environment, and periodically even without a specific trigger. A vendor risk assessment frozen at the moment of onboarding, with no refresh over two years, is not "reasonable and appropriate" under current enforcement expectations. Waiting for an incident to justify re-assessment gets the causation backwards - the incident is evidence the re-assessment should have already happened.

What it turns on: how much has changed since intake - the vendor's subprocessors, their access scope, any new integrations, their own breach history, and whether your BAA still reflects current data flows. A stable, narrowly-scoped vendor with no material changes needs a lighter refresh than one whose footprint has grown or who's had public security incidents. The pediatric hospital case likely involved exactly this - a vendor whose risk profile shifted without anyone revisiting it.

Practically: set a defined re-assessment cadence for all BAA vendors, tiered by data sensitivity and access level, and put it in writing as policy, not habit. Start with this vendor now - request their current SOC 2 or pen test results, confirm subprocessors, and document the review regardless of outcome.

No, and you should not rely on that advice. Under HIPAA, the 60-day clock runs from the date the breach is discovered, and discovery is imputed to you the moment any of your agents discovers it, not the moment you personally learn of it. The affiliate's status as its own NPI is irrelevant to that analysis; what matters is whether the affiliate is acting as your agent under a common-law agency test, meaning whether you control the manner and means of how it performs the intake function. If the affiliate operates that portal under your direction, using your specs, your security requirements, your approval rights over vendors, it is very likely your agent, and the clock started when its staff found the incident, not when they got around to telling you.

That is exactly the exposure the Interim HealthCare situation highlights, franchise-style structures where the parent assumed it had the full 60 days from its own notification, and OCR did not see it that way.

Pull your BAA and any franchise agreement now and check two things: how "discovery" is defined, and what internal notification deadline you impose on affiliates, it needs to be materially shorter than 60 days, ideally 5 to 10, to leave you room to investigate and notify HHS on time.

The obligation to assess is yours, not the vendor's, at least as the first mover — HIPAA doesn't let you wait for a subcontractor to tell you whether a breach occurred before you start your own risk assessment clock running. Your BA agreement with each health system almost certainly requires you to report incidents "without unreasonable delay," and that duty is triggered by your discovery of a security incident affecting PHI you're responsible for, not by the vendor's confirmation of impact. If the tag manager sits in your data flow and touches patient scheduling pages, you're a business associate (or your vendor is your subcontractor), and the risk-of-compromise analysis has to happen at your level regardless of what the vendor concludes about its own environment.

What it turns on: whether PHI actually flowed through or was stored on the affected infrastructure, what your BAA with the vendor says about incident notification timing and cooperation, and whether the vendor can give you enough forensic detail to complete a low-probability-of-compromise determination yourselves. If the vendor stonewalls or can't scope the blast radius, that doesn't pause your clock — it just means you conduct the assessment with the information available and document the gaps.

Pull your BAA with the vendor now and check the notification and cooperation clauses, then formally request their forensic scope-of-impact findings in writing with a deadline. Don't wait passively.

Neither location automatically wins just because that's where the lab sits or where the patient happened to ask. HIPAA sets the federal floor: 30 days, with one permitted 30-day extension if you notify her in writing. State law only displaces that floor when it is more protective of the patient's access rights, and the question of which state's law reaches you turns on where your operations are licensed and regulated, not on where the patient was standing when she made the request.

Here's what matters: you draw specimens in Georgia, which almost certainly means you're licensed or registered there as a clinical laboratory and subject to Georgia's patient-access rules for records generated from that draw site, regardless of where you store or process the data afterward. If Georgia's timeline is shorter than HIPAA's 30 days, that shorter deadline controls for those records. Florida's rules would govern only records or operations that have no Georgia touchpoint at all.

Practically, confirm your Georgia lab licensure status and pull the specific access-request deadline under Georgia's medical records statute, then compare it against HIPAA's 30 days. Build your intake workflow to flag "Georgia draw site" requests and route them to the shorter deadline by default, rather than defaulting everything to Sarasota's clock. When in doubt, honor the shorter deadline - it's never a violation to respond early.

No, automatic timestamping does not by itself satisfy your accounting-of-disclosures obligation, and I'd push back on the vendor's framing before you retire anything.

Two things are getting conflated here. First, under federal HIPAA, an accounting of disclosures under 164.528 generally excludes treatment, payment, and operations disclosures altogether — TPO releases typically aren't required to be logged in the first place, so if that's genuinely all

Yes, that gap is actionable on its own, because the Security Rule requires your risk analysis to be updated when new threat information becomes available, and a specific FBI/CISA advisory naming Medusa's exploitation of unpatched VPNs is exactly the kind of information that triggers that obligation. Once an advisory like that exists, "we didn't know" stops being available to you, and a risk analysis that's silent on a known, named threat to a technology you actually run looks stale on its face.

What it turns on is whether you had unpatched, internet-facing VPN infrastructure in scope when the advisory dropped, and how long it's been since your risk analysis was last touched. If your VPN was already patched and your risk analysis was updated within a reasonable window after the advisory, the omission is a documentation lag, not a deficiency. If the VPN was exposed and your analysis predates the advisory by months with no update, that's a live gap, and if it never gets addressed and something happens, it will read very badly to OCR or a plaintiff's expert.

Two things to do now: confirm patch status on every VPN endpoint today, not after this memo, and get your risk analysis amended to name Medusa's TTPs specifically, with a dated addendum showing you acted on the advisory rather than ignored it.

Yes, unauthorized snooping is itself an impermissible access to PHI and is presumed to be a breach under the HIPAA Breach Notification Rule unless you can document, through a risk assessment, that there is a low probability the PHI was compromised. Viewing alone satisfies "acquired, accessed, used, or disclosed" - you don't need proof of copying or downstream disclosure to trigger the analysis. The absence of copying or printing is a factor that helps your risk assessment, but it doesn't exempt you from doing one.

What it turns on: the four-factor risk assessment - nature and extent of the PHI viewed (was it just names and appointment types, or did it include diagnoses, SSNs, financial data), who did the viewing (a workforce member bound by your policies, versus an outsider), whether the information was actually used or further disclosed, and whether you've mitigated the risk. Forty records over three months with no evidence of use is not automatically low-risk just because it sounds contained - you need to actually document the analysis patient by patient or in aggregate, not just assert curiosity as an excuse.

Pull the audit logs now and identify exactly which patients and what data elements were viewed. Run the four-factor assessment in writing, patient by patient if the record types vary. If you conclude low probability of compromise, document why in detail - that memo is your defense if OCR ever asks.

Yes, your own notification obligation is separate and runs from your BA relationship with the practice, not from whatever the RCM vendor does upstream. HIPAA's breach notification duty attaches to any breach of unsecured PHI by a business associate, and it attaches independently at each link in the chain that holds the data. The RCM vendor's breach and notification to the practice doesn't discharge your duty if the same PHI sat in your backup images or endpoint telemetry and was itself accessed, exfiltrated, or otherwise compromised.

The key fact question is whether your copies were actually implicated. If the RCM vendor's breach never touched your environment, and your backups and telemetry remain intact and uncompromised, you likely have nothing to report — you just weren't part of that incident. But if the same credentials, network path, or endpoint that was compromised upstream also gave access to your systems, or if forensics can't rule that out, you have your own breach to assess and likely notify on, independent of the vendor's timeline or determination.

Practically: get your BAAs with these ninety practices reviewed now for notification triggers and timeframes, not after an incident. And build an incident response protocol that treats "upstream vendor breach" as a trigger to immediately check your own logs and backup integrity — don't wait for the vendor to tell you whether you're affected.

No, you can limit notification to the affected tenant if your forensic investigation genuinely supports that scope, but the BAA obligation tracks the Breach Notification Rule's risk assessment, not the other way around. Notification duty is triggered by unauthorized acquisition, access, use or disclosure of PHI, and your obligation runs to each covered entity whose PHI was actually or reasonably believed to be compromised. If credentials belonged solely to one tenant's application layer, and your forensics can affirmatively show no cross-tenant data access, no shared credential reuse, and no lateral movement into the hypervisor or network layers touching other tenants' environments, then the other 399 practices have no compromised PHI to report.

This turns entirely on the quality and defensibility of your forensic scoping. Shared hypervisor and network layers raise the practical question of whether you can rule out lateral movement with confidence, not just absence of evidence of it. Log retention, time-bound access reviews, and whether the compromised credential had any technical path to other tenants' data stores all matter. If your logging is thin or the credential had broader IAM permissions than expected, "no evidence of lateral movement" becomes a much weaker basis to stand on.

Get outside forensic counsel to validate scope before you decide, document the boundary rationale in writing, and check whether individual BAAs impose notification obligations broader than HIPAA's minimum, some of your 400 contracts may require notice regardless of confirmed scope.

Yes, it does. Your instinct is right, and the sales engineer is wrong. Under HIPAA, a business associate is anyone who creates, receives, maintains, or transmits PHI on your behalf, and "maintains or transmits" is enough on its own — actual viewing or use of the content is not required. This is the same logic OCR has applied for years to conduit versus non-conduit services: a vendor whose product routes data through its own cloud infrastructure, stores it even transiently, and could access it if it chose to, is not a mere conduit like a telecom carrier. It's a business associate.

It turns on what's actually in that telemetry. If the file hashes, process names, and metadata never include or reasonably risk including PHI — no patient names in filenames, no PHI in memory scans, no screen capture — you might have an argument the data isn't PHI at all, which would moot the BAA question. But across nine sites with real clinical workstations, that's a hard claim to sustain; file names, folder paths, and cached data routinely contain patient identifiers, and EDR tools by design inspect broadly to catch threats.

Don't accept the vendor's characterization. Get your security team to document what the agent actually collects and where it's stored, and require a signed BAA before renewal or expansion. If they won't sign one, that itself tells you something about their risk posture.

Yes, a stale risk analysis is enough on its own. OCR has settled cases for years on the failure to conduct an accurate and thorough risk analysis as a standalone violation, without needing to show that the resulting breach caused harm or that your incident response was sloppy. The logic runs the other way from what you're hoping: if the risk analysis didn't cover the acquired ambulatory sites or the new EHR environment, OCR will argue you couldn't have identified and remediated the risks that let ransomware in, and your containment and reporting - however well executed - becomes a mitigating factor at most, not a defense to the underlying finding.

What it turns on is whether the gap is documented and whether you were already moving to close it. If you can show board-level awareness of the acquisitions and migration, a project plan to extend the risk analysis, and interim compensating controls at the new sites, that materially changes your posture in an investigation. If there's no paper trail showing you knew the risk analysis was out of date and did nothing, that's the fact pattern OCR settlements are built on.

Get the risk analysis updated now, before any incident, and document the timeline of the acquisitions, the migration, and your remediation steps as you go.

Neither one governs in isolation here - HIPAA sets the floor for what you're permitted to disclose and how much, and information blocking then asks whether you're using that discretion as a pretext to interfere with access, exchange, or use of the information. They operate on different questions. Minimum necessary lets you make a reasonable, documented judgment about scope when the requesting party hasn't specified it. Information blocking then tests your motive and effect: if your minimum-necessary determination is genuinely tailored to the purpose of the disclosure, it's not blocking, even if it results in withholding data the hub would prefer to have.

Where this gets tight is that limited-distribution drug hubs often want more clinical detail than the prescriber actually specified, and manufacturers sometimes push for broad data sharing under the banner of care coordination. If your withholding decision is driven by minimum necessary and applied consistently, you're on solid ground. If it's driven by competitive concerns, contract leverage over the manufacturer, or a blanket policy that isn't tied to purpose, you have an information-blocking exposure, particularly since specialty pharmacy data flows are now squarely within regulators' sightlines.

Document your minimum-necessary methodology for this specific hub relationship, get the prescriber's scope of authorization in writing where you can, and have counsel review the hub's data use agreement before your next data cycle.

No, that's not how "discovery" works, and your vendor's advice is going to get you in trouble. Under the breach notification rule, discovery occurs on the first day the breach is known to your organization, or by exercising reasonable diligence would have been known, and that includes knowledge held by any of your workforce members, not just a formal determination by your investigation team. A confirmed incident is knowledge. You don't get a free ten-day head start just because you've labeled that period "investigation."

What it turns on is what "confirmed" meant when your team first had it. If a workforce member had facts sufficient to know unauthorized access or acquisition of PHI had occurred, the clock started then, regardless of when your forensics vendor finished its report or when someone with authority formally signed off. The one legitimate exception is a documented reasonable-diligence gap, where the facts genuinely weren't knowable yet. That's narrow and fact-specific, not a fixed ten-day buffer you get to claim by policy.

Go back and pull the actual timeline: when did the first person who works for Meridian have facts pointing to compromise, not when did legal or IT management get briefed. Fix your incident response policy so it defines discovery consistent with the regulatory standard, not the vendor's version, before this becomes an OCR conversation instead of a policy one.

The moment the compromise is at the account or shared-service layer, your investigation obligation extends to all 400 practices by default, not just the ones where you can show a query hit. Under the Breach Notification Rule, the presumption is that unauthorized access is a breach unless you can demonstrate, through risk assessment, a low probability that PHI was compromised. When the intrusion point is infrastructure everyone sits on, "we didn't find evidence" for a given tenant isn't the same as "we affirmatively ruled it out." You need the latter to narrow the scope.

What changes the answer is what your logging actually supports. If you have granular, tenant-level access logs, query logs, and network flow data going back far enough to positively account for which tenants' data paths were and weren't touched, you can defensibly limit notification to the affected subset. If logging is coarse, was disabled for parts of the environment, or doesn't reach back to the likely intrusion window, you can't prove a negative for the untouched tenants, and the safer legal posture is to treat the whole footprint as potentially affected.

Get a forensic firm engaged under privilege now, and have them tell you in writing what your logs can and cannot rule out before you draw any lines around who gets notified.

This is a great question.  If you are the covered entity, with the relationnship with the patient, you are ultimately responsible.  However, this can also be covered contractually.  Review your contract language

If the data was truely encrypted is is not considered PHI and therefore there is no reporting requirement.

This is incorrect