Happy New Year! What is 2019 likely to bring concerning new privacy law(s) and changes to HIPAA itself? Well no one knows for sure but the recent Facebook debacle(s) and Mark Zuckerberg's less than forthright testimony according to many Senators, has the hill clamoring for new privacy law, probably something along the lines of GDPR although not as ambitious; because many on the hill have concluded that the giant tech companies are incapable of self-regulation. Big brother to the rescue.
The need for Privacy has been a long time coming, and many knowledgeable observers felt that it was likely inevitable, although probably not in 2019. Why? Because outside of HIPAA, which only protects a patient's personal information, the U.S. does not have a national privacy law that protects personally identifiable information ("PII") generally. A new federal law would do exactly that.
What impact would a new law protecting PII have on HIPAA? Well at first maybe nothing at all; laws move slow. However, in time we might expect to see concepts such as "Privacy by Design" and "Privacy by Default" expressly reflected in the HIPAA regulations just as they are today in GDPR. So that begs the questions "what do these concepts mean?" and "how should they be implemented?"
What is Privacy by Design?
Privacy by design is an approach to systems engineering initially developed by
Ann Cavoukian and formalized in a joint report on privacy-enhancing technologies by a joint team of the Information and Privacy Commissioner of Ontario (Canada), the Dutch Data Protection Authority, and the Netherlands Organization for Applied Scientific Research in 1995. The privacy by design framework was published in 2009 and adopted by the International Assembly of Privacy Commissioners and Data Protection Authorities in 2010. Privacy by design calls for privacy to be followed throughout the whole engineering process.
In other words, anytime you start building a new "App" you should consider how privacy will be implemented as an integral part of the design. That's easy enough to state but hard to do because by its very definition both software development and privacy are wicked problems. One way to think about how and where to incorporate design is by using the OSI Stack as a go by:
Although clearly, it should be obvious that the "Application Layer" is where the "privacy logic" should be incorporated, the OSI model functions at too high a level of abstraction to be of much use. Why? Because the "Application Layer" itself is not this single monolithic block. It is generally broken down into the following layers: (1) User Interface; (2) Business Logic; and (3) Database as depicted to the right. The "privacy logic" should be included early on in the Business Logic as part of the original design, instead of some "bolt-on" that is added after the fact as a kluge.
What is Privacy by Default?
Privacy by Default means that instead of presenting the User of an Application with a bewildering array of privacy options, the strictest privacy options should be selected by the application as the "default option," thereby allowing the User to increasingly allow more access as he or she becomes better acquainted with how the publisher intends to use the data acquired. Historically, and for obvious reasons, publishers have not followed this principle. The GDPR makes it law that this principle must be followed, and moreover, it may also be true if the U.S. adopts a new privacy law. After all, from a public policy perspective, it is the User's interests that are being protected, and the inference amongst policymakers is that users prefer more, rather than less, privacy.
Implementation?
As always, the devil is in the details. One thing is to mandate what some may consider "motherhood and apple pie" platitudes and another is actually to make enforceable law that accomplishes the objective. These concepts themselves are abstractions, and it is difficult enough to legislate pursuant to concrete things let alone concepts that are amorphous. However, that did not stop the EU when it promulgated the GDPR. It just mandated that they be done and left all the details to the relevant stakeholders. Make it happen, or at a minimum one supposes, convince the GDPR authorities as to why in a particular instance it can't be done.
It is not that the concepts themselves are difficult to understand, this article should help you with that. It's more the nature of a wicked problem that changes how organizations operate and almost always proves to be a more difficult problem than what was apparent on its face.
Privac
