Generated Narrative: StructureDefinition hr-consent Name Flags Card. Type Description & Constraints Consent 0..* Consent A healthcare consumer's or third party's choices to permit or deny recipients or roles to perform actions for specific purposes and periods of time Slices for extension 1..* Extension Extension Slice: Unordered, Open by value:url extension:tenant S 1..1 Identifier Owning site tenant URL: https://fhir.savannahghi.org/ig/healthy-route/StructureDefinition/hr-tenant status S 1..1 code draft | active | inactive | not-done | entered-in-error | unknown Slices for category S 1..* CodeableConcept Classification of the consent statement - for indexing/retrieval Slice: Unordered, Open by value:coding.system category:permission S 1..1 CodeableConcept Which permission this resource records Binding: Consent Permission Value Set (required) coding S 1..1 Coding Code defined by a terminology system system S 1..1 uri Identity of the terminology system Required Pattern: https://fhir.savannahghi.org/ig/healthy-route/CodeSystem/hr-consent-permission subject S 1..1 Reference(Healthy Route Patient) Who the consent applies to date S 1..1 date Date the participant signed period S 0..1 Period Period over which the permission applies grantor S 1..1 Reference(Healthy Route Patient | RelatedPerson) Who is granting rights according to the policy and rules grantee S 1..* Reference(Healthy Route Organization) Party the permission is granted to controller S 0..* Reference(Healthy Route Organization) Data controller sourceReference S 0..1 Reference(Healthy Route Consent Evidence) The photographed signed page regulatoryBasis S 0..* CodeableConcept Regulatory framework the consent was taken under policyBasis S 1..1 BackboneElement Computable version of the backing policy url S 1..1 url Versioned identifier of the approved information sheet policyText S 0..* Reference(Healthy Route Document) The approved blank information sheet and consent form verification S 1..1 BackboneElement Consent Verified by patient or family verified S 1..1 boolean Has been verified verifiedBy S 1..1 Reference(Healthy Route Practitioner) Person who took consent verificationDate S 1..1 dateTime When consent verified decision S 1..1 code permit or deny Documentation for this format
The record that a participant granted or refused one permission, and the index to the page they signed.
Establishes the lawful basis for every subsequent resource held about the participant. A screening encounter, a specimen or a retinal image that cannot be traced to an active consent for the permission it relies on is a finding at audit, and this resource is what makes that traceable rather than a matter of correspondence.
A healthcare consumer's or third party's choices to permit or deny recipients or roles to perform actions for specific purposes and periods of time
A record of a healthcare consumer’s choices or choices made on their behalf by a third party, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time.
Broadly, there are 3 key areas of consent for patients: Consent around sharing information (aka Privacy Consent Directive - Authorization to Collect, Use, or Disclose information), consent for specific treatment, or kinds of treatment and consent for research participation and data sharing.
If the resource is contained in another resource, it SHALL NOT contain nested Resources
If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource
contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().ofType(canonical) | %resource.descendants().ofType(uri) | %resource.descendants().ofType(url))) or descendants().where(reference = '#').exists() or descendants().where(ofType(canonical) = '#').exists() or descendants().where(ofType(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated
contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
If a resource is contained in another resource, it SHALL NOT have a security label
When a resource has no narrative, only systems that fully understand the data can display the resource to a human safely. Including a human readable representation in the resource makes for a much more robust eco-system and cheaper handling of resources by intermediary systems. Some ecosystems restrict distribution of resources to only those systems that do fully understand the resources, and as a consequence implementers may believe that the narrative is superfluous. However experience shows that such eco-systems often open up to new participants over time.
A resource should have narrative for robust management
The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
Within the context of the FHIR RESTful interactions, the resource has an id except for cases like the create and conditional update. Otherwise, the use of the resouce id depends on the given use case.
The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
A set of rules under which this content was created
A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.
Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of its narrative along with other profiles, value sets, etc.
This element is labeled as a modifier because the implicit rules may provide additional knowledge about the resource that modifies its meaning or interpretation
The base language in which the resource is written.
Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
Text summary of the resource, for human interpretation
A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
Contained resources do not have a narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, nor can they have their own independent transaction scope. This is allowed to be a Parameters resource if and only if it is referenced by a resource that provides context/meaning.
This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags in their meta elements, but SHALL NOT have security labels.
Must have either extensions or value[x], not both
Identifies the site tenant that owns the resource.
May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R5/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the resource that contains them
Identifier for this record (external references)
Unique identifier for this copy of the Consent Statement.
This identifier identifies this copy of the consent. Where this identifier is also used elsewhere as the identifier for a consent record (e.g. a CDA consent document) then the consent details are expected to be the same.
CON-4 (Consent Form Number – EI) Note: An implementation-specific requirement will be needed
draft | active | inactive | not-done | entered-in-error | unknown
Indicates the current state of this Consent resource.
draft is used between the point at which the participant signs and the point at which the record has been checked against the paper. A draft consent does not authorise any activity.
Withdrawal is recorded by setting this to inactive. The resource is not deleted and its content is not altered, so the fact that consent was once held, and the date it ceased, remain available to an auditor.
This element is labelled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid
CON-11 (Consent Status – CNE using table HL70498)
Sliced by coding system to require exactly one permission code while permitting the HL7 consent category codes alongside it.
Classification of the consent statement - for indexing/retrieval
A classification of the type of consents found in the statement. This element supports indexing and retrieval of consent statements.
A classification of the type of consents found in a consent statement.
CON-2 (Consent Type - CWE using table HL70496)
One permission per resource. A participant who is asked three questions on one form is represented by three resources sharing a date and a source reference.
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
A reference to a code defined by a terminology system.
Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.
Allows for alternative encodings within a code system, and translations to other code systems.
fhir:CodeableConcept.coding rdfs:subPropertyOf dt:CD.coding
The identification of the code system that defines the meaning of the symbol in the code.
The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should be an absolute reference to some definition that establishes the system clearly and unambiguously.
Need to be unambiguous about the source of the definition of the symbol.
fhir:Coding.system rdfs:subPropertyOf dt:CDCoding.codeSystem
The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured, and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.
Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.
fhir:Coding.version rdfs:subPropertyOf dt:CDCoding.codeSystemVersion
A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).
Need to refer to a particular code in the system.
fhir:Coding.code rdfs:subPropertyOf dt:CDCoding.code
A representation of the meaning of the code in the system, following the rules of the system.
Need to be able to carry a human-readable meaning of the code for readers that do not know the system.
C*E.2 - but note this is not well followed
fhir:Coding.display rdfs:subPropertyOf dt:CDCoding.displayName
If this coding was chosen directly by the user
Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays).
Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.
This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.
fhir:Coding.userSelected fhir:mapsTo dt:CDCoding.codingRationale. fhir:Coding.userSelected fhir:hasMap fhir:Coding.userSelected.map. fhir:Coding.userSelected.map a fhir:Map; fhir:target dt:CDCoding.codingRationale. fhir:Coding.userSelected\#true a [ fhir:source "true"; fhir:target dt:CDCoding.codingRationale\#O ]
Plain text representation of the concept
A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.
Very often the text is the same as a displayName of one of the codings.
The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.
C*E.9. But note many systems use C*E.2 for this
fhir:CodeableConcept.text rdfs:subPropertyOf dt:CD.originalText
The patient/healthcare practitioner or group of persons to whom this consent applies.
Constrained to Patient. Consent is never taken from a practitioner or a group in this study, and the base resource permits both.
Date the consent instance was agreed to.
The date on the paper form, which may precede the date the record was created.
Compared against the date of the earliest study activity. An encounter, specimen or image dated before this is a protocol deviation, and the comparison is only possible if the signature date rather than the data entry date is recorded here.
CON-13 (Consent Decision Date/Time – DTM)
Period over which the permission applies
Effective period for this Consent Resource and all provisions unless specified in that provision.
Distinct from the retention period stated in the information sheet. Present where the permission itself is time limited.
Who is granting rights according to the policy and rules
The entity responsible for granting the rights listed in a Consent Directive.
Ordinarily the participant. RelatedPerson is admitted because both protocols provide for consent given by a legally authorised representative, and an earlier version of this profile constrained the element to Patient while its own comment said the resource must not preclude that. Where a representative consents, subject remains the participant and grantor is the representative, which is the distinction the two elements exist to carry.
The entity responsible for complying with the Consent Directive, including any obligations or limitations on authorizations and enforcement of prohibitions.
In a fully computable consent, both grantee and grantor will be listed as actors within the consent. The Grantee and Grantor elements are for ease of search only.
The information sheet names the parties who will hold the data. Where a permission extends beyond the site to a party receiving the exported data, both appear here, and a permission naming only the site does not authorise transfer.
The actor that manages the consent through its lifecycle.
The actor that controls/enforces the access according to the consent.
The source on which this consent statement is based. The source might be a scanned original paper form.
The source can be contained inline (Attachment), referenced directly (Consent), referenced in a consent repository (DocumentReference), or simply by an identifier (Identifier), e.g. a CDA document id.
Potential mappings to CON-5,6,7,8,16,19, 20-23
A reference to a consent that links back to such a source, a reference to a document repository (e.g. XDS) that stores the original consent document.
Optional, and expected to be absent at most sites. The protocol requires the investigator to retain the signed form and states that no records may be transferred to another location or party without written notification to the sponsor; it requires the medical record to carry a statement that consent was obtained and the date, which this resource satisfies without an image. Present only where a site has chosen to hold a photograph of the page within its own tenant and its ethics committee has approved that, which is a decision beyond the protocol rather than one it mandates.
Regulatory framework the consent was taken under
A set of codes that indicate the regulatory basis (if any) that this consent supports.
The national research regulation that governs the site, which differs between participating countries. Country variation is carried on instances rather than by separate profiles.
CON-3 (Consent Form ID and Version – ST) Note: An implementation-specific requirement will be needed
Computable version of the backing policy
A Reference or URL used to uniquely identify the policy the organization will enforce for this Consent. This Reference or URL should be specific to the version of the policy and should be dereferencable to a computable policy of some form.
Extensions that cannot be ignored even if unrecognized
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
A Reference that identifies the policy the organization will enforce for this Consent.
While any resource may be used, Consent, PlanDefinition and Contract would be most frequent
Versioned identifier of the approved information sheet
A URL that links to a computable version of the policy the organization will enforce for this Consent.
Identifies a version, not a document to display. The document itself is referenced from policyText.
Ethics committees approve a specific version of the participant information sheet and consent form. Establishing which version a participant was shown is the first question asked when a form is amended mid-study, and it cannot be answered from the signature alone.
The approved blank information sheet and consent form
A Reference to the human readable policy explaining the basis for the Consent.
The unsigned template as approved, identical for every participant given that version. Not to be confused with sourceReference, which is the individual signed page and is identifying.
Whether a treatment instruction (e.g. artificial respiration: yes or no) was verified with the patient, his/her family or another authorized person.
Extensible list of verification type starting with verification and re-validation.
This allows the verification element to hold multiple use cases including RelatedPerson verification of the Grantee decision and periodic re-validation of the consent.
The person who conducted the verification/validation of the Grantor decision.
The individual, not the organisation and not the role they held. The base resource admits all three; an organisation cannot be delegated to take consent, and recording the role rather than the person would leave the identity of the signatory on the paper form unmatched in the record. Where the delegation itself needs to be established, a PractitionerRole referring to the same practitioner carries it.
Good clinical practice requires that consent be taken by a person authorised to do so on the delegation log, and the protocol requires that person to sign the form. Recording who took it is what allows that authorisation to be checked after the fact.
Who verified the instruction (Patient, Relative or other Authorized Person).
Allows for history of verification/validation.
Action to take - permit or deny - as default.
A refusal is recorded as an active consent with a decision of deny, not as an absent resource. The distinction between a participant who declined and a participant who was never asked is material at audit.
Required, where the base resource makes it optional. A consent record whose decision is absent cannot be acted on, and its absence is indistinguishable from a refusal that was never recorded.
Sets context for the values in .provision
Sets the base decision for Consent to be either permit or deny, with provisions assumed to be a negation of the previous level.
Constraints to the base Consent.policyRule/Consent.policy
An exception to the base policy of this consent. An exception can be an addition or removal of access permissions.
This is the bound effective time of the consent and should be in the base provision in the Consent resource.
CON-14&15 (Consent Effective Date Time, Consent End DateTime)
Who|what controlled by this provision (or group, by role)
Who or what is controlled by this provision. Use group to identify a set of actors by some property they share (e.g. 'admitting officers').
There is no specific actor associated with the exception
How the individual is involved in the resources content that is described in the exception.
How an actor is involved in the consent considerations.
Resource for the actor (or group, by role)
The resource that identifies the actor. To identify actors by type, use group to identify a set of actors by some property they share (e.g. 'admitting officers').
Note that this is the direct action (not the grounds for the action covered in the purpose element). At present, the only action in the understood and tested scope of this resource is 'read'.
Security Labels that define affected resources
A security label, comprised of 0..* security label fields (Privacy tags), which define which resources are controlled by this exception.
If the consent specifies a security label of "R" then it applies to all resources that are labeled "R" or lower. E.g. for Confidentiality, it's a high water mark. For other kinds of security labels, subsumption logic applies. When the purpose of use tag is on the data, access request purpose of use shall not conflict.
Example Security Labels from the Healthcare Privacy and Security Classification System.
Context of activities covered by this provision
The context of the activities a user is taking - why the user is accessing the data - that are controlled by this provision.
When the purpose of use tag is on the data, access request purpose of use shall not conflict.
What purposes of use are controlled by this exception. If more than one label is specified, operations must have all the specified labels.
The documentType(s) covered by this provision. The type can be a CDA document, or some other type that indicates what sort of information the consent relates to.
Multiple types are or'ed together. The intention of the documentType element is that the codes refer to document types defined in a standard somewhere.
The document type a consent provision covers.
The resourceType(s) covered by this provision. The type can be a FHIR resource type or a profile on a type that indicates what information the consent relates to.
Multiple types are or'ed together. The intention of the resourceType element is that the codes refer to profiles or document types defined in a standard or an implementation guide somewhere.
The resource types a consent provision covers.
e.g. LOINC or SNOMED CT code, etc. in the content
If this code is found in an instance, then the provision applies.
If this code is found in an instance, then the exception applies.
Timeframe for data controlled by this provision
Clinical or Operational Relevant period of time that bounds the data controlled by this provision.
This has a different sense to the Consent.period - that is when the consent agreement holds. This is the time period of the data that is controlled by the agreement.
The resources controlled by this provision if specific resources are referenced.
instance | related | dependents | authoredby
How the resource reference is interpreted when testing consent restrictions.
How a resource reference is interpreted when testing consent restrictions.
A reference to a specific resource that defines which resources are covered by this consent.
A computable (FHIRPath or other) definition of what is controlled by this consent.
Constraining the expression type for a specific implementation via profile is recommended
Provisions which provide exceptions to the base provision or subprovisions.