Name Flags Card. Type Description & Constraints <a href="datatypes-definitions.html#Signature" title="Signature : A signature along with supporting context. The signature may be a digital signature that is cryptographic in nature, or some other signature acceptable to the domain. This other signature may be as simple as a graphical image representing a hand-written signature, or a signature ceremony Different signature approaches have different utilities.">Signature N Element A Signature - XML DigSig, JWS, Graphical image of signature, etc. Elements defined in Ancestors: id, <a href="types.html#Element" title="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.">extension #xD; type Σ 0..* Coding Indication of the reason the entity signed the object(s) Binding: Signature Type Codes (Preferred) #xD; when Σ 0..1 instant When the signature was created #xD; who Σ 0..1 Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization) Who signed #xD; onBehalfOf Σ 0..1 Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization) The party represented #xD; targetFormat 0..1 code The technical format of the signed resources Binding: Mime Types (Required) #xD; sigFormat 0..1 code The technical format of the signature Binding: Mime Types (Required) #xD; data 0..1 base64Binary The actual signature content (XML Signature, JSON Jose, picture, etc.) #xD; Documentation for this format
Signature Type: A signature along with supporting context. The signature may be a digital signature that is cryptographic in nature, or some other signature acceptable to the domain. This other signature may be as simple as a graphical image representing a hand-written signature, or a signature ceremony Different signature approaches have different utilities.
There are a number of places where content must be signed in healthcare.
A Signature - XML DigSig, JWS, Graphical image of signature, etc.
A signature along with supporting context. The signature may be a digital signature that is cryptographic in nature, or some other signature acceptable to the domain. This other signature may be as simple as a graphical image representing a hand-written signature, or a signature ceremony Different signature approaches have different utilities.
The elements of the Signature Resource are for ease of access of these elements. For digital signatures (Xml DigSig, JWS), the non-repudiation proof comes from the Signature validation, which includes validation of the referenced objects (e.g. Resources) (a.k.a., Content) in the XML-Signature Detached form.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
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.
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.
Indication of the reason the entity signed the object(s)
An indication of the reason that the entity signed this document. This may be explicitly included as part of the signature information and can be used when determining accountability for various actions concerning the document.
Examples include attesting to: authorship, correct transcription, and witness of specific event. Also known as a "Commitment Type Indication".
An indication of the reason that an entity signed the object.
This should agree with the information in the signature.
A reference to an application-usable description of the identity that signed (e.g. the signature used their private key).
A reference to an application-usable description of the identity that is represented by the signature.
The party that can't sign. For example a child.
used when the signature is on behalf of a non-signer.
The technical format of the signed resources
A mime type that indicates the technical format of the target resources signed by the signature.
"xml", "json" and "ttl" are allowed, which describe the simple encodings described in the specification (and imply appropriate bundle support). Otherwise, mime types are legal here.
The mime type of an attachment. Any valid mime type is allowed.
A mime type that indicates the technical format of the signature. Important mime types are application/signature+xml for X ML DigSig, application/jose for JWS, and image/* for a graphical image of a signature, etc.
The actual signature content (XML Signature, JSON Jose, picture, etc.)
The base64 encoding of the Signature content. When signature is not recorded electronically this element would be empty.
Where the signature type is an XML Signature, the signed content is a FHIR Resource(s). The signature can be XML Signature or JSON Jose form, e.g. XML-Signature can be generated for a Resource in JSON format.