Stream: implementers
Topic: FHIR Resource Location/Link/URL
Debbie Bucci (Jun 14 2021 at 13:35):
Not sure if this is the right place to post but ... Are resource locations considered PII? My initial thought is no but I have heard otherwise. Have any implementer out there had this constraint/business rule to contend with?
Grahame Grieve (Jun 14 2021 at 16:47):
resource locations? You mean the id of the resource itself?
Merlyn Albery-Speyer (Jun 14 2021 at 17:57):
Some FHIR implementations support defining the id of a resource on creation with a REST API PUT. That opens the door for you to add PII as the id. I think it's bad practice to do that.
Grahame Grieve (Jun 14 2021 at 17:58):
some servers do that natively. It's generally a bad to use a human usable Id as a resource id because there's almost always processes to 'fix' things about the id
Debbie Bucci (Jun 14 2021 at 18:12):
Sorry if I am not clear - just the domain resource resource ID - (think I got that right ) - Not writing anything but storing that link/location - no PII directly - would need proper access to know more ...resource location
Grahame Grieve (Jun 14 2021 at 18:14):
well, in principle, it's tricky. As already discussed the identifier that humans use should not be the resource id, and so in that sense, the resource location is not PII.
That doesn't mean that it shouldn't be protected though, but for different reasons than PII
Grahame Grieve (Jun 14 2021 at 18:15):
at least, that's my view
Debbie Bucci (Jun 14 2021 at 18:17):
Protected of course - access control, policy etc - Its the source system's choice of what they use - but I guess you are saying -- if human readable identifier is used - that may be considered PII at that point - thus tricky
Grahame Grieve (Jun 14 2021 at 18:18):
if a human readable identifier that is PII is used for a resource id, than it's definitely PII
Debbie Bucci (Jun 14 2021 at 18:19):
But otherwise ... probably not ...?
Grahame Grieve (Jun 14 2021 at 18:20):
right. at least, that's my take.
Debbie Bucci (Jun 14 2021 at 18:25):
Thanks much for the response - that's my take too. If its already a FHIR best practice - then asking source systems to align may cover most of that problem.
Grahame Grieve (Jun 14 2021 at 18:26):
I'm not sure that it's a documented best practice.
Debbie Bucci (Jun 14 2021 at 18:27):
Well if there is a process to petition to do so ... please let me know
Debbie Bucci (Jun 14 2021 at 18:33):
In re: to the POST - yes I do recall reading somewhere that there may be a business need to change but there was explicit instructions regarding how to retain the source information. Maybe that was on the bulk update $import discussion - in the extension section I believe
Grahame Grieve (Jun 14 2021 at 18:51):
well, you can raise a create a task - link at the bottom of every page in the spec
Grahame Grieve (Jun 14 2021 at 18:52):
actually, there is this: https://www.hl7.org/fhir/resource.html#identifiers
Debbie Bucci (Jun 14 2021 at 19:10):
Thanks for the link ! May be a good place to note. I had read early on but now after a bit of practice on the re-read the distinction between resource location and business Identifier is an important one. I had assumed that the resource ID would never change - but, If I am reading correctly, that's for a particular version AND should assume that would be updated over time - no guarantee of history. Will give it more thought.
Grahame Grieve (Jun 14 2021 at 19:57):
no it will never change
Debbie Bucci (Jun 14 2021 at 20:53):
Ok original assumptions correct(ed) thank you. It's the version history that may not be retained. Whether a resource is accessible is beyond the scope of my concern (and this thread) that goes to policy access etc.
Lloyd McKenzie (Jun 25 2021 at 22:08):
In addition to the id, the base part of the URL could also be sensitive. For example, a "supportingInformation" link to "http://hivtreatmentcentre.org/Condition/1234567" could be sensitive even if 1234567 is completely opaque.
Last updated: Apr 12 2022 at 19:14 UTC
