SMART server can return Person resource to identify user if Patient or Practitioner or RelatedPerson doesn't work

[isaacvetter]

@whitehatguy laid out these rules on the SMART google group to define what FHIR resource should be used to represent the current user with the profile/fhirUser claim:

1. For practitioners, use "Practitioner" resource.
2. If the records being shared are those of the authenticated user, use "Patient" resource.
3. For others, use "Person" resource.

We should replace references to RelatedPerson with Person.

[jmandel]

We should discuss the merits of saying "Always use Person when it's not a Patient or Practitioner" vs saying "Use RelatedPerson if possible and Person if not". The key point is that RelatedPerson captures the specific details/relation, and superficially at least it makes sense to use/keep this when possible (rather than prohibiting it).

[isaacvetter]

Hey @jmandel ,

Why not always used RelatedPerson, but sometimes have an empty RelatedPerson.relationship ?

[michelemottini]

In our server we have pretty much to use Person: you log-in as a user - that does not really have any corresponding FHIR resource beside person,. and a user can be a patient or a practitioner or neither.

We have also RelatedPerson in our database, but as a completely separate concept from users - so not really usable in connection with the authorization process

[isaacvetter]

Hey @michelemottini - Practitioner essentially maps to "user" in non-patient facing apps. The Person FHIR resource seems to be intentionally abstract and primarily intended for complex identity mapping.

In your system, do your Person resources contain a link reference to Practitioner, Patient or RelatedPerson?

[michelemottini]

I our system Person (user) can link to a Practitioner or to a Patient or neither. Never to a RelatedPerson

[daliboz]

RelatedPerson (as a singular) doesn't work if I'm logging is as mom with access to my dependents or spouses. Essentially, any "patient" login where I have user/* scopes.

[jmandel]

Agreed @daliboz! And thanks for the context @michelemottini. I think the decision we'll want to make is: which subset of {Patient, Practitioner, RelatedPerson, Person} we want to support at the level of the specification.

We've heard use cases for all four, on my view -- though that doesn't mean we need to support all four.