Friday, September 23, 2016

Mobile Health Cloud vs Privacy Regulations

There is some strong discussion going on at HL7 around privacy concerns, especially now that HL7 FHIR has enabled easy application writing.  The discussion started with an article "Warning mHealth security fears are opening doors to app and device innovation" summarizing a study done by Ketchum.  There is concern that applications are being written by people that might not be as mature in the knowledge of how important Privacy is in healthcare.
  • There are concerns that new regulations will stifle innovation. I disagree...
  • There are recommendations that broader healthcare regulations are needed. I disagree...
  • There are concerns that identifiers for patients will be bad for Privacy. I disagree...
  • Some indicate that application developers don't care about privacy until a breach puts them in trouble. I disagree...
Let me explain my disagreement... I will also say that I agree with these concerns, just not in broad terms.

This problem of mobile-applications and Privacy is not unique to Healthcare. It is the scope of HL7, so understandable to be focused on it there. I point this out because from a Privacy and Security perspective we are far better off solving the problem together with all domains, than trying to solve it uniquely for healthcare. Healthcare does have some unique issues, like that the data can't be revoked or recalled.

The issue is somewhat unique to the USA, because of the extreme fragmented Privacy regulations. Although we do have HIPAA, GINA, 42-CFR Part 2, and many state augmentations. This patchwork of privacy regulations makes it very hard to understand the requirements, only very large organizations have the legal resources to untangle this all into one concept.

Privacy regulations are not important to instruct application writers on how to do the right thing.


Many application developers want to do the right thing so they gain access to Privacy-by-Design, and other Privacy Principles. These application developers design Privacy into their application, and thus Privacy does not get in the way.

Privacy regulations are important to deal with the application developers that don't try to honor Privacy; or those that actively thwart Privacy. Regulations are needed so that bad behavior can be detected, and prosecuted. Don't focus on Regulations to drive the right thing, look to them to prevent the wrong thing. In a perfect world there is no reason for regulations. A perfect world is where everyone wants to do the right thing for their peers, and have full resources to figure out what that right thing is. We don't have a perfect world... yet.

Mobile applications and the cloud are not limited by physical boarders, so they really need to look at the world. The problem that we have in the USA, is the same problem at a global scale. There is a huge patchwork of privacy regulations globally. The solution is the same, put Privacy first. Use Privacy-by-Design and other Privacy Principles. Make your application the best Privacy supporting application, and it will work everywhere (everywhere that governments themselves don't thwart privacy principles)

Build Privacy in from the beginning and it is not hard to do nor will it take away from a good user experience. Hack it on later and it is surely going to be problematic.  Apple is a good example of building Privacy in by design, and they have few (not zero) issues. Where as Facebook is a good example of hacking privacy on later, although they pushed through the hard part and are much better now.

The CBCC workgroup in HL7 is trying to do their part, they are creating a Privacy Handbook that all HL7 workgroups can use when they create new standards to assure that any Privacy Considerations are handled either in the standard they are creating or explained to the reader of that standard. This same thing is done by W3C, IETF, and OASIS; so we are solving the problem together with those domains.

If you can't protect the data, then don't collect the data.

Other Privacy topics covered on these articles.

Thursday, September 8, 2016

HL7 ballot:Guidance on Standards Privacy Impact Assessment

The CBCC workgroup has published a 'handbook' for comment in the current HL7 ballot. This handbook is to be used by the workgroups within HL7 for the purposes of producing HL7 standards that have 'considered' privacy. The expectation is that when a standard has considered privacy, it will be more easy to assure privacy when it is implemented.

Fortunately this is a first draft, and a draft for comment... so one hopes that major changes can be done.

I have voted negative with a three dozen comments, mostly negative. The problem this handbook has is that it is asking an HL7 workgroup, while they are writing an interoperability standard, to do a Privacy Impact Assessment, using Privacy by Design. These are great tools, but are tools that are focused on an operational environment. Trying to apply them to the design of a HL7 interoperability standard is impossible, or at best too difficult.

Which should have been obvious to the authors of this HL7 SPIA, given that the conclusion of each of 10 steps is to write into the target specification the same boiler plate text to follow regulations. This should have made it very clear that they were using the wrong tool for the job.

I recommended from the start of this project, and my negative comments reflect this, that HL7 follow the lead of IETF and W3C. They have an approach that supports PIA and PbD; but is cast into actions that an interoperability standard developing workgroup can properly execute. They use terminology that is understandable, or well defined. They have reasonable steps, and reasonable activities.  

HL7 is a standards organization, we expect the standards we produce to be used. We expect that the healthcare domain will not ignore HL7 and invent their own solution. Thus as a standards organization, we should look to other standards organizations that have already created standards that are applicable, and USE THOSE STANDARDS. Why are we re-inventing what IETF and W3C have already produced?  I think it is fully appropriate that we cast their text into terms that the HL7 community uses, however even that gap is narrowing with FHIR.

Reference:

Tuesday, September 6, 2016

Looking for career opportunity

As some of you know, I am currently exploring new career opportunities. Who best to reach out to than those who understand and are interested in what I do through following my blog. Topics such as Privacy Consent, Access Control, Audit Control, Accounting of Disclosures, Identity, Authorization, Authentication, Encryption, Digital Signatures, Transport/Media Security, De-Identification, Pseudonymization, and Anonymization..In the spirit of good networking I'd like to share my thoughts and objectives for my next adventure. Any thoughts, feedback, suggestions, or contacts would be greatly appreciated.

I seek to be considered for an Interop Architect, Interop Program Manager, Standards Developer, Privacy Architect, or other similar leadership position that allows me to continue to engage with International Standards development while directing one or more teams in the implementation of those standards. My philosophy is that Interoperability Standards are not a destination, they are a catalyst that enables something far greater to happen. Privacy is not a encumbrance, but an enabler of something far greater.

I have over 30 years of experience with IT communications, including 18 years of expertise in Healthcare Interoperability Standards and the application of Privacy. I have worked closely with product development teams working on small medical devices, big medical devices, health information systems, and cloud workflows combining all.

I am especially excited about the latest standard from HL7 - FHIR. The FHIR standard leverages modern platforms and interaction models. It models the healthcare data-model using XML or JSON; and interaction-model using http REST.

I currently hold a co-chair position in HL7 security workgroup, as well as a leadership position in HL7 FHIR Management Governance. I am recognized as a leader on the topics of Privacy, Security, and Interoperability in DICOM, IHE, and HL7.  I wish to continue with my engagement with HL7, IHE, and DICOM standards organizations. Interoperability standards allow for the best re-use of technical implementations. These standards set the basis upon which we will add-value.

I have significant experience interacting with government bodies to help them with the evaluation of Interoperability Standards, and the writing of regulations to improve healthcare. I was a member of the HIT Standards - Privacy and Security workgroup, Direct, HITSP, and CCHIT before that. I have influenced USA regulations such as HIPAA, and Meaningful Use; as well as regional regulations globally. I am a member of the Wisconsin HIE technical advisory committee, and provide technical advice to the USA national eHealth Exchange. I have advised HIE implementations in Saudi Arabia, Italy, France, EU, etc

I am a true believer that Privacy + Interoperability are not just equal to the sum of the parts; but enable something greater than could ever happen without them.  I openly and eagerly advise and encourage through 7 years of  blogging,

See my Resume/CV on LinkedIn https://www.linkedin.com/in/johnmoehrke

Comments, Suggestions, Recommendations are welcome. I don't expect my readers have job opportunities sitting there waiting. However I do expect that you might know someone who knows something is happening...

PS. It appears I am going to miss the September HL7 meeting in Baltimore. This is my second miss in a row due to not having an employer.  This is sad for me as I look forward to being able to interact with my peers face-to-face.

PPS. I am not a "Security Architect". I love the security architects, they do a hugely important service for Privacy. I just don't find the kind of focus on defense to be fun. I am far more interested in enabling the right use of data (Privacy), than trying to stop the mass of maleficence.

PPPS. Happy birthday to my blog... now 7 years old.