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.
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.
- Basic Consent - a necessary first step
- Aiding Online Informed Consent using Social Commentary
- Consent Process
- Controlling Big-Data feeding frenzy with Privacy Consent Authorization
- Vectors through Consent to Control Big-Data Feeding frenzy
- Consent Basis in Controlling Big-Data Feeding frenzy
- Privacy Constraints in Controlling Big-Data Feeding Frenzy
- electronic Privacy Consent -- Patient choice
- Privacy-by-Design Data-Analytics Platform on FHIR
- Simplified #FHIR Privacy Consent Directive resource
- Consent given to authorized representative
- Patient ID is critical to Enabling Privacy
- electronic Privacy Consent -- Patient choice
- BPPC is not just for XDS/XCA
- Consent to grant read access to a specific types of FHIR Resources
- How to set the ConfidentialityCode
- Strawman on Consent Directive
- Privacy Principles
- Break-Glass on FHIR
- Healthcare Patient Consent -- Lessons learned from Creative Commons
- Enabling Patients to Delegate Healthcare Information Access Authority
- Define Atom -- Too many definitions in use today
- Defining Privacy
- Safety vs Privacy
- Privacy Consent State of Mind
- Universal Health ID -- Enable Privacy
- Texas HIE Consent Management System Design
- Simple and Effective HIE Consent
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
- Data Segmentation - now I know where the term comes from
No comments:
Post a Comment