Stream: implementers
Topic: Partial Identifiers
Bruce Tietjen (Apr 12 2016 at 16:25):
What is an appropriate way to express an 'identifier' resource where a portion of the identifier value must be suppressed due to security/legal or other reasons. Examples: last 4 digits of a U.S. Social Security number, last 4 digits of a credit card number, etc.
Bruce Tietjen (Apr 12 2016 at 17:21):
The issue we specifically wish to address is the last 4 digits of the Social Security number. For legal reasons, using the full SSN must be limited to specific use cases. Use of the last 4 digits is a more common situation and hopefully could be represented in much the same way that the full SSN is represented. The full SSN is represented using <system value="http://hl7.org/fhir/sid/us-ssn"/> in the identifier. It would be helpful if there were a corresponding system for the last 4 digits -- maybe something like: <system value="http://hl7.org/fhir/sid/us-ssn4"/>
Lloyd McKenzie (Apr 12 2016 at 18:47):
Similar use-case can exist for credit card numbers, phone numbers, postal codes and a bunch of other things. Options could include: Creating an extension called "partial value" that could appear in those data types. Another alternative would be to have specific "use" types for partial identifiers, partial phone numbers, partial addresses, etc. A third possibility would be to have a convention of replacing missing digits with leading asterisks and accept that incorrect matches could occur.
Preferences? Other ideas?
Grahame Grieve (Apr 12 2016 at 19:12):
There's an extension for this already
Grahame Grieve (Apr 12 2016 at 19:13):
http://hl7-fhir.github.io/extension-rendered-value.html
Lloyd McKenzie (Apr 12 2016 at 19:38):
Do you know why we didn't allow for it on string generally? (Or at least on postal code?)
Grahame Grieve (Apr 12 2016 at 20:01):
I didn't define it
Brian Postlethwaite (Apr 12 2016 at 21:37):
If that is used then should really be including the subsetted met tag right?
Brian Postlethwaite (Apr 12 2016 at 21:37):
As shouldn't just be posting that resource back witgout knowning that the content wasn't complete.
Brian Postlethwaite (Apr 12 2016 at 21:40):
Now that I re-read this, seems a little odd to me, passing the sensitive data out and including some text to show with it. I would have thought that would be more approproate to have meta tag indiacting that content is not complete, and this extension (or one like it) to mark the fields that have been masked.
And require some different security context or action (break glass etc) to be able to get at the content that would then imply additional logging that the sensitive content was exposed.
Brian Postlethwaite (Apr 12 2016 at 21:41):
Thinking further on this, I think this part would be more likely for including a pre-formatted display content for a string, rather than masking the original value.
so ID stored as 55545352 but displayed to the user as (555) 45-352
Lloyd McKenzie (Apr 12 2016 at 21:52):
We don't want the SSN sent in identifier/value/@value as 1234. Because that implies we've actually got a SNN. Instead, we send identifier/value/extension/valueString. That's completely safe.
Grahame Grieve (Apr 12 2016 at 21:52):
well, the whole case is kooky. The system needs the full identifier, but the user doesn't see it. But that implies a certain amount of trust in the system that isn't in the user. In other cases, you couldn't trust the user, and you wouldn't send an identifier at all
Lloyd McKenzie (Apr 12 2016 at 21:54):
You could choose to include the @value (and trust the system to not show it) or exclude the @value entirely and still send the extension (and not confuse anyone that an @value was actually present)
Brian Postlethwaite (Apr 12 2016 at 21:55):
For Credit card details, wouldn't pass PCIDSS testing if the value was in there. (Not that we currenlty have that data in FHIR - just an example)
Brian Postlethwaite (Apr 12 2016 at 21:56):
I think we are mixing 2 use cases, 1 for alternate displays of data, and another for masking sensitive content
Lloyd McKenzie (Apr 13 2016 at 00:40):
True, but their manifestations are the same. Communicating a piece of data in a slot where a "full" set of data is expected, but communicating it in a way that represents what should be shown to the user, not what can be used for computation. Whether what's to be displayed has masked content or represents the full data with separator characters added or dates turned into named months or whatever doesn't really matter. From a computation and rendering perspective, the behavior is identical.
Lloyd McKenzie (Apr 13 2016 at 00:40):
And it supports both use-cases where the computable data is transmitted too and those where it's not.
Lloyd McKenzie (Apr 13 2016 at 00:41):
In terms of "protected" data, you'd want to be very cautious about sharing the computable value with any system that you weren't positive would protect it from being displayed to inappropriate users - including enforcing similar protections on down-stream systems.
Lloyd McKenzie (Apr 13 2016 at 00:41):
But that's about what data you agree to send, not whether the extension works.
Brian Postlethwaite (Apr 13 2016 at 02:05):
Yup, that covers it.
John Moehrke (Apr 13 2016 at 12:19):
You would NOT use the subsetted tag for this... subsetted is specifically for when less data is returned because of NON security issues (like the client asked for _summary). If this is masked then it needs to be tagged as masked... all for the very reason Brian points out. But I wanted to make it clear that there are many tags that need to be viewed by the recipient as indicating that the data is less than complete for different reasons.
John Moehrke (Apr 13 2016 at 12:22):
I do find this use-case really disturbing. You are willing to send HEALTH DATA to a recipient while not trusting them with a full SSN. I know the organizations that have this viewpoint; and I know why. They are causing pain wherever they interconnect. This is one of the prime reasons why Patient Identity Matching is problematic (not the only problem, but a big one). Far better that healthcare be declared a legitimate use of the SSN. sorry, rant with no solution.
John Moehrke (Apr 13 2016 at 12:29):
I think Bruce has the best solution. Give this 'type' of identifier a unique system. Then the system can decide to return the full ssn, or the ssn fragment, or both. The ssn is not a unique identifier anyway, there are duplicates and errors. so to consider the fragment not worthy, while considering ssn worthy, seems like an arbitrary rule. How much confidence is necessary before an identifier qualifies as an identifier? In the space of De-Identification, the fragment is still considered a "Direct Identifier".
Chris Grenz (Apr 13 2016 at 16:24):
An identifier system where system+value is explicitly not unique is problematic...
Lloyd McKenzie (Apr 13 2016 at 16:49):
Which is why you would include the value/@value
Lloyd McKenzie (Apr 13 2016 at 16:49):
(Or if you did, it would have to be the full value)
Chris Grenz (Apr 13 2016 at 16:58):
Sorry...not following that last comment.
John Moehrke (Apr 13 2016 at 17:44):
Even the full SSN is not explicitly unique. It is a best-effort... but there are plenty of documented cases where legitimately multiple people are assigned the same SSN. Even more cases where multiple are illegitimately using the same SSN.
Chris Grenz (Apr 13 2016 at 17:46):
Right, but that's a quality/matching issue, not a situation where the design intent includes duplicates.
John Moehrke (Apr 13 2016 at 17:47):
I agree. I very much would like to totally discourage any use of partial SSN... however I, nor HL7, can control that; so it is best to contain that.
Chris Grenz (Apr 13 2016 at 17:50):
I'd argue that a partial SSN isn't an identifier (as in the built-in Patient.identifier) but rather some other attribute (extension ,maybe of type Identifier, maybe just string).
Michelle (Moseman) Miller (Apr 13 2016 at 19:04):
As an FYI for context, this gForge change request http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=8665 is what led to the creation of the extension, http://hl7-fhir.github.io/extension-rendered-value.html -- specifically it allows determination of appropriate display to be performed by a server where formatting rules may not be known by or may be too complex to be performed by a client
Lloyd McKenzie (Apr 13 2016 at 20:32):
You're conveying an SSN. You're just not conveying all of it. Which means that you can't put your string in Identifier/value/@value. And because there's nothing specified there, you don't have to worry about it not being globally unique.
Last updated: Apr 12 2022 at 19:14 UTC
