SecurityPrincipal FHIR Resource Proposal

SecurityPrincipal

Rejected due to the content of a User Account is not a healthcare specific concept, or is sufficiently profiled elsewhere. Use of the standards identified are recommended without HL7 defined constraints. See the FHIR Security page for details.

Owning committee name

FHIR Core Project

Contributing or Reviewing Work Groups

• Security
• IHE

FHIR Resource Development Project Insight ID

FHIR core project

Scope of coverage

Some implementations find that it would be useful to be able to manage user accounts and rights through the FHIR interface. This is true whether they use their own user identity system, or some external identity provider such as LDAP, Windows Domain, or Facebook/Google/etc,since even when using these external identity providers, there are still rights/roles things to say that are specific about FHIR. So we have decided that FHIR will provide a specific set of resources for this. Note that it will not be required for an implementation to use these resources in order to implement it's security system - they are defined for convenience should an implementation wish one.

See FHIR Security Management Subsystem for further information.

The SecurityPrincipal resource allows a system to describe either human user or a device/software application that is authorised to use the FHIR API, and manage both how it is authenticated, and what authorisations it has.

• subject: either device or person (or perhaps organisation)
• usage: manage authentication and/or authorization
• this resource is not limited by discipline/context/locality

RIM scope

• A principle is an entity (Person/Organisation/Device) playing the role of Licensed Entity (LIC)

Resource appropriateness

This resource represents:

• a well understood, "important" concept in the business of healthcare - an authenticated user.
  • note: this concept is not healthcare specific, which is why this resource and it's related resources are a subsystem that are not allowed to become an API dependency
• a concept (user/device) expected to be tracked with distinct, reliable, unique ids
• a concept that is created, queried and maintained
• the initial proposal expects 10 elements
• is well decoupled from other concepts

Expected implementations

• the FHIR reference server will implement this
• several other connectathon attendees have asked for this functionality

Content sources

• IHE XUA
• IHE PWP
• LDAP
• OpenID Connect
• Microsoft Documentation - WCF Security & LDAP documentation

Example Scenarios

• define user/software that is allowed to use a server
• define claims for rights that apply to an identified user or software application

Resource Relationships

• this resource refers to other resources that identify the same principal (patient, practitioner, organization, device)
• this resource refers to a security rights group for grouping claims of rights
• there is also a SecurityRole group for defining additional roles a user may claim

Timelines

Fro development for QA/DSTU2

gForge Users

Core team