Stream: implementers
Topic: Using the patient-compartment to define a patients record
Jack Burnett (Jul 27 2020 at 15:38):
Hey, am considering the ramifications of using the patient-compartment to determine which patient a piece of data is about.
The definition of the $everything endpoint (https://www.hl7.org/fhir/operation-patient-everything.html) says that it can be used to get a patients entire record, and also says that is achieved by returning everything in the patient-compartment (and other stuff in addition).
But from looking at the patient compartment (https://www.hl7.org/fhir/compartmentdefinition-patient.html), it seems like it would include data that isn’t necessarily from a Patients record.
For a specific example, Observation; it searches on both the subject or performer parameter. The inclusion of performer seems to imply it would include data that wasn’t necessarily about that Patient, for example if they were marked as a performer on an Observation for their child.
So my question is, what is the reasoning behind including Observation.performer in the patient-compartment and, more generally, is it actually sensible to use the patient-compartment to determine who a resource is about (both for authorisation purposes and more generally to decide if it is part of a patients medical record).
John Moehrke (Jul 27 2020 at 15:53):
interesting find. This would seem to align the definition of patient compartment closer with "what the patient has authorization to" that it is aligned with the concept of "this is information about the patient as the subject". The parent / child use-case seems like a good use-case for authorization perspective; but as you point out there is a need to get just the data where the patient is the subject (so not children or elder-care or spouse-care)
John Moehrke (Jul 27 2020 at 15:53):
@FHIR-I Co-chairs ?
John Moehrke (Jul 27 2020 at 15:55):
note that compartment is a concept in security (Attribute Based Access Control) that would work this way
Lloyd McKenzie (Jul 27 2020 at 15:56):
Agree that the Patient compartment is more about 'access' than 'who's it about'. It may be that the $everything wording needs to be tightened. What it really does is find everything that matches using the 'patient' search parameter - which would be less than everything in the Patient compartment. Can you submit a change request @Jack Burnett for us to clarify the description of $everything?
John Moehrke (Jul 27 2020 at 15:57):
This would be a good clarification that the fine-grain-SMART could leverage too...
Jack Burnett (Jul 28 2020 at 07:40):
Thanks both, will submit that change request.
Though I still question the correctness of having child resources in their parents compartment.
If we totally set aside the $everything endpoint for now;
The compartment definition page for patient (https://www.hl7.org/fhir/compartmentdefinition-patient.html) lists as the description “The set of resources associated with a particular patient”.
So in terms of how you’d use that for authorisation, I figured you would be granting users access to certain compartments, and thus granting them access to the records of the patients those compartments compare too.
So the preferred usage would simply be to grant the parent access to both their compartment AND their Childs compartment, rather than having access to those child resources be implicit in their own compartment.
That way you could more easily turn off the parents access - for example when that child becomes an adult themselves.
Of course I appreciate that the desired behaviour here may vary by use case quite a bit!
Though even if you do think that the current behaviour is working as intended, I would suggest modifying the compartment definition itself to make it more clear that it may contain resources not directly related to the patient.
John Moehrke (Jul 28 2020 at 12:03):
I agree. which is why I was surprised. I would have expected the patient compartment to truly be patient centric. I do think we are too focused right now on child. I wonder if the intent of indicating that patient compartment might have data that was not directly associated with the patient as leading toward resources that are medically relevant to the patient, but are not attributed to that patient. I would expect any resource that is dual subject, would just have both subjects listed. Thus I am not sure what falls into these edge cases. Might the variation have been put there simply to deal with edge cases that are not predictable, and they had no specific examples?
Last updated: Apr 12 2022 at 19:14 UTC
