This page is part of the FHIR Specification (v4.4.0: R5 Preview #2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
Security Work Group | Maturity Level: 0 | Trial Use | Security Category: Not Classified | Compartments: Not linked to any defined compartments |
Permission.
The Permission resource is intended to capture why data can be shared. It can be applied in two complementary situations:
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).
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 ]
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 |
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 ]
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
Path | Definition | Type | Reference |
---|---|---|---|
Permission.status | Codes identifying the lifecycle stage of a product. | Required | PermissionStatus |
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 |