Stream: implementers
Topic: FHIRPath in Consent
Shamil Nizamov (Mar 16 2021 at 15:53):
Can Consent.provision.class be used to withhold/disclosure of specific information using FHIRPath rather than a resource type?
For example, if a patient decided to withhold only his/her gender, would it be possible to define Patient.gender in the Consent.provision.code?
Lloyd McKenzie (Mar 16 2021 at 15:59):
@David Pyke
David Pyke (Mar 16 2021 at 16:00):
Boy, you're quick...
LOINC code LP189571-5 is Gender identity, so yes, if you're using LOINC to define what's being suppressed, then that would work
Elliot Silver (Mar 16 2021 at 16:19):
@David Pyke, I'm not sure that's what's being asked (although that may be what they want). Can you use FHIRPath to define the elements to withold?
David Pyke (Mar 16 2021 at 16:30):
WE haven't really worked with a use case to have an expression define the required filter. That being said, it could be done but would need to be an extension
Shamil Nizamov (Mar 16 2021 at 16:44):
This is exactly what we are trying to avoid, i.e., using codes that (suddenly) may change. It's quite easier to define the restricted element by the FHIRPath. For example:
<provision>
<type value="deny"/>
...
<class>
<system value="http://hl7.org/fhir/resource-types"/>
<code value="Patient"/>
</class>
<code>
<coding>
<system value="http://hl7.org/fhirpath"/>
<code value="Patient.gender"/>
</coding>
</code>
...
</provision>
PS. Should I submit a ticket to consider including FHIRPath or may be to introduce a new element for that?
David Pyke (Mar 16 2021 at 17:38):
Yes please!
ryan moehrke (Mar 16 2021 at 17:42):
I would think you would have to define a new element to use fhirpath in, as if the binding is extensible it would be non-compliant to have a second way to represent "patient's gender" as a code.
David Pyke (Mar 16 2021 at 17:47):
Absolutely. We would need an element that uses an expression, kind of like http://hl7.org/fhir/metadatatypes.html#Expression
Shamil Nizamov (Mar 16 2021 at 17:50):
Why? Since the .code is CodeableConcept I should be able to use the following:
<code>
<coding>
<system value="http://loinc.org"/>
<code value="76691-5"/>
</coding>
<coding>
<system value="http://hl7.org/fhirpath"/>
<code value="Patient.gender"/>
</coding>
</code>
David Pyke (Mar 16 2021 at 17:54):
You might be able to but people will likely want to do more than that so it may be better to set up FHIRPath expressions in the resource itself
David Pyke (Mar 16 2021 at 17:55):
And I don't believe FHIRPath is a registered code system so that may cause issues
Shamil Nizamov (Mar 16 2021 at 17:58):
I'm puzzled a bit, could you show an example with the FHIRPath expression in this context?
And I likely need to submit a ticket to include FHIRPath to the FHIR Terminology as well.
David Pyke (Mar 16 2021 at 18:00):
Creating FHIRPath as a codesystem is more than just a ticket. That would be a major project.
Lloyd McKenzie (Mar 16 2021 at 18:20):
FHIRPath isn't a code system. It doesn't define "concepts". It doesn't provide definitions. It's a different thing. An extension that points to Expression is a much better path
Shamil Nizamov (Mar 16 2021 at 18:32):
David Pyke said:
Yes please!
Created: FHIR-31550
Shamil Nizamov (Mar 16 2021 at 19:08):
Lloyd McKenzie said:
FHIRPath isn't a code system. It doesn't define "concepts". It doesn't provide definitions. It's a different thing. An extension that points to Expression is a much better path
I know. But while waiting for a better option, and for internal use only, and trying to avoid extension which may be too much, such quick and dirty non compliant solution may work.
Jean Duteau (Mar 16 2021 at 19:17):
how would abusing a code be "too much" than just defining an extension which would be exactly what you need?
Lloyd McKenzie (Mar 16 2021 at 19:23):
A non-compliant solution should never be preferable to using an extension. Extensions are normal and a completely reasonable way to handle special requirements. Abusing core elements is not a good plan.
John Moehrke (Mar 16 2021 at 21:52):
I think this is the model that we are looking at in Permission
John Moehrke (Mar 16 2021 at 21:53):
what we need are some real examples to work on. theory has only taken us so far
Elliot Silver (Mar 17 2021 at 03:31):
One downside to using FHIRPath for disclosure consent is that it would be tied to a specific attribute (or perhaps enumerated attributes). Using a "do not disclose gender" code would allow the server to target administrative sex, gender observations, and potentially things like certain procedures or conditions, etc.
Jose Costa Teixeira (Mar 25 2021 at 12:51):
The trick(s) would be not to do that (only on ) the instance, but doing it on the profiles ("all patient genders that leave this server")
And on data class ("all things tagged as potentially sensitive")
And on clusters of data ("whenever we see a Postal code AND a date of birth")
Jose Costa Teixeira (Mar 25 2021 at 12:52):
Is there an approach that does not have such downside?
Jose Costa Teixeira (Mar 25 2021 at 12:55):
@Shamil the idea of providing additional content for the codes is close to the tagging of the data, but in this case you are tagging the actual value. I presume that can also be addressed by FHIRPath.
Jose Costa Teixeira (Mar 25 2021 at 12:56):
It's not clear if your use case is
a) Patient says "I do not consent to sharing my gender data"
b) hospital says "in this system, for that purpose, with that entity, we do not share gender data"
Jose Costa Teixeira (Mar 25 2021 at 12:56):
a) is Consent
b) is Permission land
Jose Costa Teixeira (Mar 25 2021 at 12:57):
Permission.dataScope is an Expression exactly for these purposes
Last updated: Apr 12 2022 at 19:14 UTC
