Slashdot Mirror


FTC Fines Software Vendor Over False Data Encryption Claims (softpedia.com)

An anonymous reader writes: The US Federal Trade Commission (FTC) has fined a software vendor for lying about its product's encryption capabilities, despite being publicly warned by US Computer Emergency Readiness Team (CERT) not to do so. The software vendor is Henry Schein, who deliberately ignored CERT and FTC warnings and continued to sell its CRM for dentists, even if it knew it did not comply with HIPAA rules. The vendor got "only" a $250,000 fine.

5 of 37 comments (clear)

  1. not scarequotes needed by Gravis+Zero · · Score: 5, Informative

    yes, they were only fined $250K. Henry Schein is a multibillion dollar multinational company. $250K is "cost of business" expense because they make millions selling their software. this isn't even a slap on the wrist.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:not scarequotes needed by l0n3s0m3phr34k · · Score: 3, Informative

      And yet they won't; per HIPAA encryption is "Addressable" and not "Required". 45 CFR 164.312 is actually really short and is completely tech agnostic.

    2. Re:not scarequotes needed by budgenator · · Score: 3, Informative

      You have to read the FTC complaint and have experience dealing with Schein to understand what's really going on. It's my opinion that the use of encryption was not for the purpose of protecting patient information from unauthorized release to ne'er–do–wells, but to make the difficulty of migrating Our data to a new vendor's Dental Practice Management System unnecessarily difficult.

      Schien as a company is like a stereotype of all the worst qualities of Microsoft, Oracle and SAP.; they are my company of last resort.

      --
      Apocalypse Cancelled, Sorry, No Ticket Refunds
  2. Re:Does Rust ensure HIPAA-compliant software? by l0n3s0m3phr34k · · Score: 3, Informative

    No, because HIPAA is totally tech agnostic. The security protocols in HIPAA are only a few pages; encryption is "Addressable" yet not "Required" unlike "Unique User Identification". They are designed so a normal "office manager" can do a checklist; they are in no way "security protocols" like an actual IT compsec person would design.

    "Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information."
    "Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."

    That's pretty much the tech level of the entire document, there are no actual technologies referenced in it. Technically you could indeed use Pig Latin as your "encryption", but actually don't need to have any encryption at all.

  3. Rickety pile of smouldering crap by Dr.Dubious+DDQ · · Score: 3, Informative
    I've been working for an organization that uses Dentrix. My impression of it is...not very favorable.

    It seems like someone wrote a basic customer-tracking database for Windows that happened to be focussed on dental patients, and then Henry Schein bought them and built the rest by "buying" (or "licensing") connections to a pile of other third-party software. In addition to MS-SQL and Microsoft Office, this seems to include Adobe Flash in places, "integrators" for at least two different third-party imaging software packages, a messaging system, and who knows what else.

    Looking at the CERT notice, I'm guessing they "bought" (/"licensed") their special "proprietary encryption" as a package from Faircom and just bolted it on without any further examination. They were probably happily going along continuing to brag about their encryption because Faircom was, and they figured Faircom could be blamed for it.

    It doesn't help that "Dental-patient record tracking software" isn't a particularly big niche, so there's likely very little competition and any half-assed thing they throw together will continue to generate license fees because Big Multibillion-Dollar Corporation can easily outmarket the very few competitors they may have (and who may not actually be any better). Many years ago, I worked for a proprietary retail inventory-and-point-of-sale software developer. Their product was also a rickety pile of smouldering crap, but it still seemed to be better than most of their few competitors back then. Horrifying, but I suspect Henry Schein is in an analogous situation (compounded by being a massive conglomerate).