Stream: implementers
Topic: Signature
Pranitha Sruthi (Nov 14 2017 at 12:12):
Hi all, what are the extensions provided for the data type 'Signature'? Moreover, how can I capture both initial and normal signatures? Thank you
Lloyd McKenzie (Nov 14 2017 at 14:56):
As yet, there are no extensions defined for the Signature data type. However, signature has a "type" element that should be able to distinguish for you. What are "initial" and "normal" signatures?
John Moehrke (Nov 14 2017 at 15:15):
I would recommend multiple Provenance records for each of those changes to the resource being signed. Thus each Provenance explains why the change was made, and thus each holds the 'current' signature.
John Moehrke (Nov 14 2017 at 15:18):
an example is where a client requests a Create of a resource. It could come with a Provenance.signature. The server, which needs to fixup some of the elements like id, would validate the client signature; create the instance of the resource with the fixup, create a new Provenance with a new signature. Best case that new signature counter-signs the original signature to indicate that the original signature was validated initially.
John Moehrke (Nov 14 2017 at 15:19):
is this what you are working on? I am not sure what else 'both initial and normal signature' mean.
Pranitha Sruthi (Nov 15 2017 at 05:29):
@John Moehrke @Lloyd McKenzie Initial signature contains only two letters first letter from the first name and second letter of the signature would be the first letter from the last name. For instance, my full name is "Sruthi Valivety", the initial signature would be SV. Whereas the normal signature is used to sign official documents.
Lloyd McKenzie (Nov 15 2017 at 09:21):
The signature data type is used for digital signatures - not for physical signatures.
Grahame Grieve (Nov 15 2017 at 09:25):
no can be used for physical signatures
Lloyd McKenzie (Nov 15 2017 at 09:28):
Then the definition needs to be loosened...
John Moehrke (Nov 15 2017 at 14:55):
We have included in the Signature datatype that the signature can be of any type that can be described by a mime-type (contentType element). Thus in the case of a physical signature, this could be digitally signed, and the JPG/PDF of that be placed into the Signature.blob. In all cases it is up the region to determine what is a legitimate signature.
John Moehrke (Nov 15 2017 at 14:56):
@Lloyd McKenzie The definition of Signature is inclusive of these kind of signatures: "A Signature holds an electronic representation of a signature and its supporting context in a FHIR accessible form. "
Lloyd McKenzie (Nov 15 2017 at 17:20):
The short description for the signature datatype says "A digital Signature - XML DigSig, JWS, Graphical image of signature, etc."
Lloyd McKenzie (Nov 15 2017 at 17:21):
The words "digital Signature" confused me.
Lloyd McKenzie (Nov 15 2017 at 17:21):
Particularly when the first two examples were clearly true "digital signatures"
Lloyd McKenzie (Nov 15 2017 at 17:22):
Perhaps a "A digital or other signature representation - ..."?
Jens Villadsen (Nov 15 2017 at 17:22):
so its not meant to support some sort of 'authenticity statement'?
John Moehrke (Nov 15 2017 at 18:16):
formally it holds an Electronic-Signature or a Digital-Signature
John Moehrke (Nov 15 2017 at 18:19):
I don't see that reversing the order of the examples is all that helpful. We would prefer a Digital-Signature, but we have use-cases where electronic-signature is needed... and can be supported just as well in the model.
John Moehrke (Nov 15 2017 at 18:24):
I entered a CP to remove the word "Digital" GF#14193: Signature datatype definition needs to be inclusive of electronic signature
Richard Townley-O'Neill (Nov 16 2017 at 05:52):
Back to the original question.
Signature.type is described as "Indication of the reason the entity signed the object(s)."
Whether a signature is a full signature or just initials seems to be a different concept (maybe "signature form") and would need an extension in STU3.
Lloyd McKenzie (Nov 16 2017 at 08:02):
Agree
Last updated: Apr 12 2022 at 19:14 UTC
