GDPR Privacy about more than just confidentiality

Rene Spronk published an excellent and very detailed article on a unique perspective drawn from the new General Data Protection Regulation (GDPR) -- aka: European Privacy Regulation. That it requires that Patients be given access to data about themselves, in a standardized, and usable form. Thus the regulation makes Interoperability Standards a requirement. Please see his article: Impact of GDPR on the use of Interoperability Standards

This perspective is driven by Privacy Principles, which are more than just Confidentiality.

The GDPR also requires that any Consent given must be understood by the subject regardless of their age, education, or human language issues. Thus any organization gathering data must provide various forms of their consent language that can be proven to be understood by that patient. The FHIR Consent supports this by having a place to record the actual text presented to the patient. Clearly deriving that text originally is not a FHIR issue. It is a very difficult task, and I feel for small organizations. Similar capability to record the actual text presented to the patient is also available in IHE BPPC which supports APPC for this purpose.

As with any Privacy regulation one must have good Provenance proof of where all data came from, including when it was imported from the Patient themselves. One must also have good AuditEvent records to show where and why the data was used.

See my Privacy Consent topic table of contents
And my FHIR topic table of contents

Human Names - remedial testing

Humans around the world have very difficult to deal with names. But even the most simplistic names can be problematic. Here is a specific case I have run into lately. We have had a problem where a person had a apostrophe in their name, and it caused failures. This because in the API (string based API), a person name is quoted using single quote... yet if it includes a quote, that terminates the string early... oops.

So I poked around, and don't find a test bench that does much of a good job at testing string elements that are intended to be human names. I did find a fantastic QA article from W3C. But I would consider what they have outlined as "advanced". 

Remedial would be a far more basic set... The closest I find is the definition in LDAP. That definition for PrintableString.

      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
                           PLUS / COMMA / HYPHEN / DOT / EQUALS /

                           SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")

   The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
   [RFC4512].

PrintableString has a few characters in it that are uncommon in a human name (never say never). But it does clearly indicate the 7-bit ASCII alpha, number, hyphen, space, period, and apostrophe. This set would work fine for many countries, okay it would only work for USA... But that is why I call it remedial.

      RemedialCharacter = ALPHA / DIGIT / SQUOTE / HYPHEN / DOT / SPACE

      RemedialName    = 1*RemedialCharacter

Beyond this one mostly needs all the alpha from unicode...See the W3C QA specification. but I haven't quite figured that one out.

    https://www.w3.org/International/questions/qa-personal-names

Mostly, I am thinking that for Provider Directory, and Patient Directory.... that testing should have test script that test for this remedial, and optionally for the full unicode...  And, they need to deal with searching, and sorting... topics well beyond advanced, but very very important.

Again... I don't think remedial is enough, but if one can't get past remedial they are clearly not ready for real person names