This page is part of the FHIR Specification (v4.6.0: R5 Draft Ballot - see ballot notes). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

6.5 Resource Permission - Content

Security

Work Group

Maturity Level: 0

Trial Use

Security Category: Not Classified

Compartments: Not linked to any defined compartments

Permission.

6.5.1 Scope and Usage

The Permission resource is intended to capture why data can be shared. It can be applied in two complementary situations:

Describe why a specific capability or implementation is permitted to process data
Describe why a given resource or set of resources are allowed to exist and/or be shared

The Permission model is related to privacy laws like GDPR, and it intended to support implementations meet some of regulatory requirements. For example, having a Permission associated with an interface (data transfer) supports a registry of Processing Activities (Art. 30 of GDPR).

6.5.2 Boundaries and Relationships

6.5.2.1 Consent

In many situations in healthcare, Consent is not necessary or a valid reason for processing data or sharing. Data can be shared due to

Legal reasons: For example, mandatory reporting of infectious diseases - regardless of any positive or negative consent from the patient, some diagnosis must be submitted to the authorities

6.5.3 References

No resources refer to this resource directly.

This resource does not implement any patterns.

Structure

Name	Flags	Card.	Type	Description & Constraints
Permission	TU		DomainResource	Permission Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
status	Σ	1..1	code	active \| entered-in-error \| draft \| rejected PermissionStatus (Required)
intent	Σ	0..1	CodeableConcept	grant\|refuse
asserter	Σ	0..1	Reference(Person)	The person or entity that asserts the permission
assertionDate	Σ	0..*	dateTime	The date that permission was asserted
validity	Σ	0..1	Period	The period in which the permission is active
purpose	Σ	0..*	CodeableConcept	The purpose for which the permission is given
dataScope	Σ	0..*	Expression	This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements
processingActivity	Σ	0..*	BackboneElement	A description or definition of which activities are allowed to be done on the data
partyReference	Σ	0..*	Reference(Organization)	If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person
partyCodeableConcept	Σ	0..*	CodeableConcept	If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type § Purpose – a specific purpose of the data
purpose	Σ	0..*	CodeableConcept	The purpose for which the permission is given
justification	Σ	0..1	BackboneElement	The asserted justification for using the data
evidence	Σ	0..*	Reference(Consent)	Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot
grounds	Σ	0..*	CodeableConcept	This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
usageLimitations	Σ	0..*	CodeableConcept	What limits apply to the use of the data
Documentation for this format

UML Diagram (Legend)

XML Template

<Permission xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <status value="[code]"/><!-- 1..1 active | entered-in-error | draft | rejected -->
 <intent><!-- 0..1 CodeableConcept grant|refuse --></intent>
 <asserter><!-- 0..1 Reference(Person) The person or entity that asserts the permission --></asserter>
 <assertionDate value="[dateTime]"/><!-- 0..* The date that permission was asserted -->
 <validity><!-- 0..1 Period The period in which the permission is active --></validity>
 <purpose><!-- 0..* CodeableConcept The purpose for which the permission is given --></purpose>
 <dataScope><!-- 0..* Expression This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements --></dataScope>
 <processingActivity>  <!-- 0..* A description or definition of which activities are allowed to be done on the data -->
  <partyReference><!-- 0..* Reference(Organization) If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person --></partyReference>
  <partyCodeableConcept><!-- 0..* CodeableConcept If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type
§ Purpose – a specific purpose of the data --></partyCodeableConcept>
  <purpose><!-- 0..* CodeableConcept The purpose for which the permission is given --></purpose>
 </processingActivity>
 <justification>  <!-- 0..1 The asserted justification for using the data -->
  <evidence><!-- 0..* Reference(Consent) Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot --></evidence>
  <grounds><!-- 0..* CodeableConcept This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR --></grounds>
 </justification>
 <usageLimitations><!-- 0..* CodeableConcept What limits apply to the use of the data --></usageLimitations>
</Permission>

JSON Template

{
  "resourceType" : "Permission",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "status" : "<code>", // R!  active | entered-in-error | draft | rejected
  "intent" : { CodeableConcept }, // grant|refuse
  "asserter" : { Reference(Person) }, // The person or entity that asserts the permission
  "assertionDate" : ["<dateTime>"], // The date that permission was asserted
  "validity" : { Period }, // The period in which the permission is active
  "purpose" : [{ CodeableConcept }], // The purpose for which the permission is given
  "dataScope" : [{ Expression }], // This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements
  "processingActivity" : [{ // A description or definition of which activities are allowed to be done on the data
    "partyReference" : [{ Reference(Organization) }], // If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person
    "partyCodeableConcept" : [{ CodeableConcept }], // If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type
§ Purpose – a specific purpose of the data
    "purpose" : [{ CodeableConcept }] // The purpose for which the permission is given
  }],
  "justification" : { // The asserted justification for using the data
    "evidence" : [{ Reference(Consent) }], // Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot
    "grounds" : [{ CodeableConcept }] // This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
  },
  "usageLimitations" : [{ CodeableConcept }] // What limits apply to the use of the data
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .


[ a fhir:Permission;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Permission.status [ code ]; # 1..1 active | entered-in-error | draft | rejected
  fhir:Permission.intent [ CodeableConcept ]; # 0..1 grant|refuse
  fhir:Permission.asserter [ Reference(Person) ]; # 0..1 The person or entity that asserts the permission
  fhir:Permission.assertionDate [ dateTime ], ... ; # 0..* The date that permission was asserted
  fhir:Permission.validity [ Period ]; # 0..1 The period in which the permission is active
  fhir:Permission.purpose [ CodeableConcept ], ... ; # 0..* The purpose for which the permission is given
  fhir:Permission.dataScope [ Expression ], ... ; # 0..* This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements
  fhir:Permission.processingActivity [ # 0..* A description or definition of which activities are allowed to be done on the data
    fhir:Permission.processingActivity.partyReference [ Reference(Organization) ], ... ; # 0..* If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person
    fhir:Permission.processingActivity.partyCodeableConcept [ CodeableConcept ], ... ; # 0..* If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type
§ Purpose – a specific purpose of the data
    fhir:Permission.processingActivity.purpose [ CodeableConcept ], ... ; # 0..* The purpose for which the permission is given
  ], ...;
  fhir:Permission.justification [ # 0..1 The asserted justification for using the data
    fhir:Permission.justification.evidence [ Reference(Consent) ], ... ; # 0..* Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot
    fhir:Permission.justification.grounds [ CodeableConcept ], ... ; # 0..* This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
  ];
  fhir:Permission.usageLimitations [ CodeableConcept ], ... ; # 0..* What limits apply to the use of the data
]

Changes since R3

This resource did not exist in Release 2

This analysis is available as XML or JSON.

Structure

Name	Flags	Card.	Type	Description & Constraints
Permission	TU		DomainResource	Permission Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
status	Σ	1..1	code	active \| entered-in-error \| draft \| rejected PermissionStatus (Required)
intent	Σ	0..1	CodeableConcept	grant\|refuse
asserter	Σ	0..1	Reference(Person)	The person or entity that asserts the permission
assertionDate	Σ	0..*	dateTime	The date that permission was asserted
validity	Σ	0..1	Period	The period in which the permission is active
purpose	Σ	0..*	CodeableConcept	The purpose for which the permission is given
dataScope	Σ	0..*	Expression	This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements
processingActivity	Σ	0..*	BackboneElement	A description or definition of which activities are allowed to be done on the data
partyReference	Σ	0..*	Reference(Organization)	If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person
partyCodeableConcept	Σ	0..*	CodeableConcept	If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type § Purpose – a specific purpose of the data
purpose	Σ	0..*	CodeableConcept	The purpose for which the permission is given
justification	Σ	0..1	BackboneElement	The asserted justification for using the data
evidence	Σ	0..*	Reference(Consent)	Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot
grounds	Σ	0..*	CodeableConcept	This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
usageLimitations	Σ	0..*	CodeableConcept	What limits apply to the use of the data
Documentation for this format

UML Diagram (Legend)

XML Template

<Permission xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <status value="[code]"/><!-- 1..1 active | entered-in-error | draft | rejected -->
 <intent><!-- 0..1 CodeableConcept grant|refuse --></intent>
 <asserter><!-- 0..1 Reference(Person) The person or entity that asserts the permission --></asserter>
 <assertionDate value="[dateTime]"/><!-- 0..* The date that permission was asserted -->
 <validity><!-- 0..1 Period The period in which the permission is active --></validity>
 <purpose><!-- 0..* CodeableConcept The purpose for which the permission is given --></purpose>
 <dataScope><!-- 0..* Expression This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements --></dataScope>
 <processingActivity>  <!-- 0..* A description or definition of which activities are allowed to be done on the data -->
  <partyReference><!-- 0..* Reference(Organization) If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person --></partyReference>
  <partyCodeableConcept><!-- 0..* CodeableConcept If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type
§ Purpose – a specific purpose of the data --></partyCodeableConcept>
  <purpose><!-- 0..* CodeableConcept The purpose for which the permission is given --></purpose>
 </processingActivity>
 <justification>  <!-- 0..1 The asserted justification for using the data -->
  <evidence><!-- 0..* Reference(Consent) Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot --></evidence>
  <grounds><!-- 0..* CodeableConcept This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR --></grounds>
 </justification>
 <usageLimitations><!-- 0..* CodeableConcept What limits apply to the use of the data --></usageLimitations>
</Permission>

JSON Template

{
  "resourceType" : "Permission",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "status" : "<code>", // R!  active | entered-in-error | draft | rejected
  "intent" : { CodeableConcept }, // grant|refuse
  "asserter" : { Reference(Person) }, // The person or entity that asserts the permission
  "assertionDate" : ["<dateTime>"], // The date that permission was asserted
  "validity" : { Period }, // The period in which the permission is active
  "purpose" : [{ CodeableConcept }], // The purpose for which the permission is given
  "dataScope" : [{ Expression }], // This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements
  "processingActivity" : [{ // A description or definition of which activities are allowed to be done on the data
    "partyReference" : [{ Reference(Organization) }], // If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person
    "partyCodeableConcept" : [{ CodeableConcept }], // If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type
§ Purpose – a specific purpose of the data
    "purpose" : [{ CodeableConcept }] // The purpose for which the permission is given
  }],
  "justification" : { // The asserted justification for using the data
    "evidence" : [{ Reference(Consent) }], // Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot
    "grounds" : [{ CodeableConcept }] // This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
  },
  "usageLimitations" : [{ CodeableConcept }] // What limits apply to the use of the data
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .


[ a fhir:Permission;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Permission.status [ code ]; # 1..1 active | entered-in-error | draft | rejected
  fhir:Permission.intent [ CodeableConcept ]; # 0..1 grant|refuse
  fhir:Permission.asserter [ Reference(Person) ]; # 0..1 The person or entity that asserts the permission
  fhir:Permission.assertionDate [ dateTime ], ... ; # 0..* The date that permission was asserted
  fhir:Permission.validity [ Period ]; # 0..1 The period in which the permission is active
  fhir:Permission.purpose [ CodeableConcept ], ... ; # 0..* The purpose for which the permission is given
  fhir:Permission.dataScope [ Expression ], ... ; # 0..* This can be 1) the definition of data elements, or 2) a category or label) e.g. “sensitive”. It could also be a c) graph-like definition of a set of data elements
  fhir:Permission.processingActivity [ # 0..* A description or definition of which activities are allowed to be done on the data
    fhir:Permission.processingActivity.partyReference [ Reference(Organization) ], ... ; # 0..* If the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or person
    fhir:Permission.processingActivity.partyCodeableConcept [ CodeableConcept ], ... ; # 0..* If the processing is a transfer, or involves another party, we must capture where it the data allowed or expected to be shared - with a party or person. This can be a party instance or party type
§ Purpose – a specific purpose of the data
    fhir:Permission.processingActivity.purpose [ CodeableConcept ], ... ; # 0..* The purpose for which the permission is given
  ], ...;
  fhir:Permission.justification [ # 0..1 The asserted justification for using the data
    fhir:Permission.justification.evidence [ Reference(Consent) ], ... ; # 0..* Evidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshot
    fhir:Permission.justification.grounds [ CodeableConcept ], ... ; # 0..* This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
  ];
  fhir:Permission.usageLimitations [ CodeableConcept ], ... ; # 0..* What limits apply to the use of the data
]

Changes since Release 3

This resource did not exist in Release 2

This analysis is available as XML or JSON.

See the Profiles & Extensions and the alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis a

6.5.4.1 Terminology Bindings

Path	Definition	Type	Reference
Permission.status		Required	PermissionStatus

Path

Definition

Type

Reference

Permission.status

Required

PermissionStatus

6.5.5 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Expression	In Common
status N	token	active \| entered-in-error \| draft \| rejected	Permission.status