Stream: implementers
Topic: Search by Name - Person v. Patient
Alex Gerstein (May 18 2020 at 22:40):
Hello,
We recently adjusted how we track user identity by migrating our default "user" resource from Patient to Person. We had a separate "first name" & "last name" search on Patient that mapped nicely to the "given" and "family" search parameters. It looks like these search parameters aren't available on the Person resource, so we'll likely need to add them as custom parameters.
However, we are curious: was it an intentional omission to not have the "given" and "family" search parameters on Person as well? Or are there plans to include these parameters in the future?
Thanks,
Alex
Lloyd McKenzie (May 19 2020 at 00:57):
Person is not allowed to be an actor - it can't be a performer, subject, or any other kind of participant. It solely exists as a source of shared demographic information and to act as a link between multiple Patient, RelatedPerson and/or Practitioner resources.
Lloyd McKenzie (May 19 2020 at 00:58):
(So using it for 'user' wouldn't be terribly appropriate.)
Lloyd McKenzie (May 19 2020 at 00:59):
We've tried hard to avoid stepping too much into the security space because there are other RESTful standards out there and it's not something that is healthcare-specific. Where we do explore the space a little bit is in things like AuditEvent, and there we have the choice of Patient, RelatedPerson, Practitioner, PractitionerRole, Device and Organization.
Michele Mottini (May 19 2020 at 13:13):
We do use Person to map our system users: they can be Practitioner, Patient or neither, so to implement the SMART fhirUser scope that was basically the only possible choice
Lloyd McKenzie (May 19 2020 at 15:26):
Users can often also be devices. Every actor in FHIR is always a Practitioner, Patient or RelatedPerson. If someone is acting in their professional capacity (even if they're a plumber or elevator technician), that's a Practitioner.
John Moehrke (May 19 2020 at 17:08):
Lloyd McKenzie said:
Users can often also be devices. Every actor in FHIR is always a Practitioner, Patient or RelatedPerson. If someone is acting in their professional capacity (even if they're a plumber or elevator technician), that's a Practitioner.
I had not noticed that. so Practitioner is intended to support any human actor functional/structural role outside of patient or relatedPerson. (where that role is actually declared in PractitionerRole).
Jean Duteau (May 19 2020 at 17:12):
Although I understand your point and have used Practitioner to model Users in some of my other projects, there are some applications where the "user" is not someone acting in a professional capacity, but just a person who is accessing a system. Their role in the system is dependent on how they log in to the system. So Jean Duteau is a Person who can access the system as either a Practitioner or a Patient, depending on his login or on what role he chooses when he is logging in. In that case, I've modeled (like Alex and Michele) Users as Persons who then get tied to a Patient or Practitioner (and even potentially RelatedPerson if used in reports or information capture).
John Moehrke (May 19 2020 at 17:19):
I think that is reasonable. as long as your system never has Person acting without the casting into Patient, Practitioner, or RelatedPerson. These are the three prime structural roles, upon which for Practitioner there are refined structural/functional roles that can be expressed in PractitionerRole resource.
John Moehrke (May 19 2020 at 17:29):
Might this be useful to state so boldly somewhere in the FHIR spec? Is this a topic people might look for on the security pages?
John Moehrke (May 19 2020 at 17:30):
@Lloyd McKenzie do you know if this is said this bluntly somewhere in FHIR-I pages?
Jenni Syed (May 19 2020 at 17:41):
The main gotcha here, which is where we also use Person for SMART to identify "current user" is when I am logged in to access all records I can access as a consumer user
Jenni Syed (May 19 2020 at 17:41):
I'm acting as 2+ different RelatedPersons and a Patient all in the same context
Jenni Syed (May 19 2020 at 17:43):
but the SMART "user" is really trying to identify "person in the real world that is logged in"
John Moehrke (May 19 2020 at 17:47):
understood. SMART likely should have been more true to the distinction of actors and not used person this way.
John Moehrke (May 19 2020 at 17:52):
F#27164
John Moehrke (May 19 2020 at 17:52):
Lloyd McKenzie (May 19 2020 at 18:34):
Person is not allowed to do anything. It's a strict prohibition that's part of the definition of the resource
Lloyd McKenzie (May 19 2020 at 18:35):
Person instances are never directly referenced as actors (authors, subjects, performers, etc.) Individual actors are always identified as either Patient, Practitioner or RelatedPerson, depending on the role of the individual when undertaking the action. Therefore this resource SHALL NOT be referenced by any other clinical or administrative resources. E.g. it can be the focus of an operation or message or included in a Bundle, but cannot be a member of a List or Group, the subject of an Observation, or other similar non-infrastructural usage.
Lloyd McKenzie (May 19 2020 at 18:35):
(From the scope and usage section of the Person resource)
Lloyd McKenzie (May 19 2020 at 18:38):
If we go back to the v3 space, it's not possible to participate as an Entity, you can only participate as a Role.
Jean Duteau (May 19 2020 at 18:59):
Lloyd McKenzie said:
Person is not allowed to do anything. It's a strict prohibition that's part of the definition of the resource
I don't think anyone is trying to assert that a Person is doing anything - but that they are representing the person behind the actor that is doing something. As Jenni pointed out (and I pointed out), we have a "user" who can't do anything without a role but is an actual thing that I want to convey in a FHIR manner - to me that is the Person with their demographic details. When that Person is looking up their clinical records, they are a Patient. When they are providing content for their parent or their child, they are a RelatedPerson and when they are creating records about their real-world patients, they are a Practitioner. So there is a need for a Person resource and there is a valid use case for associating a User (without Role) to a Person.
This is getting us pretty far afield from the original question:
Patient and Practitioner define "given" and "family" search parameters but Person does not - it only has the name search parameter.
@Alex Gerstein I'm not associated with the Patient Administration WG but this seems like more of an oversight than deliberate. I can't think of a reason why you explicitly disallow searching for a Person resource by their given or family name. You should raise an issue about this.
Lloyd McKenzie (May 19 2020 at 21:02):
You can't point to Person in AuditEvent or Provenance, so not sure how useful it will be to have them as 'user'
Jenni Syed (May 19 2020 at 21:13):
When they take an action, you would interpret who they are acting as
Jenni Syed (May 19 2020 at 21:13):
There's not really another way I know of to do this
Jenni Syed (May 19 2020 at 21:14):
But I agree this is a bit of drift from the original question
Lloyd McKenzie (May 19 2020 at 21:32):
In response to the original question, I don't think it was intentional - would be appropriate to submit a change request
John Moehrke (May 20 2020 at 14:18):
Lloyd McKenzie said:
You can't point to Person in AuditEvent or Provenance, so not sure how useful it will be to have them as 'user'
Audit has a secondary method, in that you can put the user-identifier in as an AuditEvent.agent.altId
And really anywhere an agent element is one can use the .identifier in the .reference --> AuditEvent.agent.who.identifier ... as one can expect that identifier likely is an identifier to be found in a Agent type resource (.identifier). -- this reasonable if there is consistent use of the .identifier element in these agent resources to hold the user-identifier... which seems to me to be a realistic recommendation that I put into J#27164
Lloyd McKenzie (May 20 2020 at 15:14):
If you're using that as a means to point to Person, I still think that falls into the scope of the SHALL NOT.
Ian Bacher (May 20 2020 at 15:28):
Just to point out for the original question, I requested the change in J#26371
Brian Postlethwaite (Aug 26 2020 at 20:07):
I don't consider this as a reference to a user in the AuditEvent/Provenance.
My personal view is that there are many ways that user's are modelled, and we can describe how they might be done, and which resources could be appropriate. It won't include any reference stuff, just informative guidance.
There are systems that only have practitioners as users, some that cover only patients, some that have modes where either is appropriate (but not both), and others have system accounts, or devices...
Also wandering into this issue is the username, what places could it be put, and just as importantly, where should it be put, and NOT put?
@John Moehrke Is this something that should be covered by the Security Workgroup?
John Moehrke (Aug 27 2020 at 13:15):
@Brian Postlethwaite I am not sure what you yet want. The Security WG has indicated to use the .identifier element to hold any identifier known. A username is just an identifier within that user assigning domain.
Last updated: Apr 12 2022 at 19:14 UTC
