Release 5 Preview #3

6.5 Resource Permission - Content

Security Work GroupMaturity Level: 0 Trial UseSecurity 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:

  1. Describe why a specific capability or implementation is permitted to process data
  2. 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).

In many situations in healthcare, Consent is not necessary or a valid reason for processing data or sharing. Data can be shared due to
  1. 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
  2. Contractual reasons: For provision of services e.g. reimbursement, performing a contract requires sharing information

No resources refer to this resource directly.

This resource does not implement any patterns.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Permission ΣTUDomainResourcePermission
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... status Σ1..1codeactive | entered-in-error | draft | rejected
PermissionStatus (Required)
... intent Σ0..1CodeableConceptgrant|refuse
... asserter Σ0..1Reference(Person)The person or entity that asserts the permission
... validity Σ0..1PeriodThe period in which the permission is active
... purpose Σ0..*CodeableConceptThe purpose for which the permission is given
... dataScope Σ0..*ExpressionThis 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..*BackboneElementA 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..*CodeableConceptIf 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..*CodeableConceptThe purpose for which the permission is given
... justification Σ0..1BackboneElementThe 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..*CodeableConceptThis would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
... usageLimitations Σ0..*CodeableConceptWhat limits apply to the use of the data

doco Documentation for this format

UML Diagram (Legend)

Permission (DomainResource)Statusstatus : code [1..1] « Codes identifying the lifecycle stage of a product. (Strength=Required)PermissionStatus! »grant|refuseintent : CodeableConcept [0..1]The person or entity that asserts the permissionasserter : Reference [0..1] « Person »The date that permission was assertedassertionDate : dateTime [0..*]The period in which the permission is activevalidity : Period [0..1]The purpose for which the permission is givenpurpose : CodeableConcept [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 elementsdataScope : Expression [0..*]What limits apply to the use of the datausageLimitations : CodeableConcept [0..*]ProcessingActivityIf the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or personpartyReference : Reference [0..*] « Organization »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 datapartyCodeableConcept : CodeableConcept [0..*]The purpose for which the permission is givenpurpose : CodeableConcept [0..*]JustificationEvidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshotevidence : Reference [0..*] « Consent »This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPRgrounds : CodeableConcept [0..*]A description or definition of which activities are allowed to be done on the dataprocessingActivity[0..*]The asserted justification for using the datajustification[0..1]

XML Template

<Permission xmlns="http://hl7.org/fhir"> doco
 <!-- 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

{doco
  "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/> .doco


[ 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

NameFlagsCard.TypeDescription & Constraintsdoco
.. Permission ΣTUDomainResourcePermission
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... status Σ1..1codeactive | entered-in-error | draft | rejected
PermissionStatus (Required)
... intent Σ0..1CodeableConceptgrant|refuse
... asserter Σ0..1Reference(Person)The person or entity that asserts the permission
... validity Σ0..1PeriodThe period in which the permission is active
... purpose Σ0..*CodeableConceptThe purpose for which the permission is given
... dataScope Σ0..*ExpressionThis 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..*BackboneElementA 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..*CodeableConceptIf 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..*CodeableConceptThe purpose for which the permission is given
... justification Σ0..1BackboneElementThe 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..*CodeableConceptThis would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR
... usageLimitations Σ0..*CodeableConceptWhat limits apply to the use of the data

doco Documentation for this format

UML Diagram (Legend)

Permission (DomainResource)Statusstatus : code [1..1] « Codes identifying the lifecycle stage of a product. (Strength=Required)PermissionStatus! »grant|refuseintent : CodeableConcept [0..1]The person or entity that asserts the permissionasserter : Reference [0..1] « Person »The date that permission was assertedassertionDate : dateTime [0..*]The period in which the permission is activevalidity : Period [0..1]The purpose for which the permission is givenpurpose : CodeableConcept [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 elementsdataScope : Expression [0..*]What limits apply to the use of the datausageLimitations : CodeableConcept [0..*]ProcessingActivityIf the processing is a transfer, we must capture where it the data allowed or expected to be shared - with a party or personpartyReference : Reference [0..*] « Organization »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 datapartyCodeableConcept : CodeableConcept [0..*]The purpose for which the permission is givenpurpose : CodeableConcept [0..*]JustificationEvidence – reference to consent, or a contract, or a policy, or a regulation, or an attachment that contains a screenshotevidence : Reference [0..*] « Consent »This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPRgrounds : CodeableConcept [0..*]A description or definition of which activities are allowed to be done on the dataprocessingActivity[0..*]The asserted justification for using the datajustification[0..1]

XML Template

<Permission xmlns="http://hl7.org/fhir"> doco
 <!-- 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

{doco
  "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/> .doco


[ 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

PathDefinitionTypeReference
Permission.status Codes identifying the lifecycle stage of a product.RequiredPermissionStatus

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

NameTypeDescriptionExpressionIn Common
status Ntokenactive | entered-in-error | draft | rejectedPermission.status