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:
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:
Post a Comment