Stream: fhir/documents
Topic: Capturing signers of a document
Corey Spears (Oct 25 2021 at 00:13):
For PACIO Advance Directives we need to be able to capture signers of the document. For the digital signature of the complete document, we are providing a method of capturing the signature outside of the document. However, for people signing the document (Bundle) we have to decide how to capture this.
The problem with Provenance seems to be that it requires a target, which is the document it is contained within. This would result in a circular reference (Bundle including a Composition which references a provenance which references the containing bundle). The persons we can capture as Patient, Practitioner, and relatedPerson, but what resources should be used to capture author, witness, and notary signatures, statements, credentials (e.g. date and jurisdiction), and the like? Note that the physical versions of these documents have signatures as part of the document. We are trying to replicate that.
Lloyd McKenzie (Oct 25 2021 at 02:02):
If you're signing a document, why would you not use Bundle.signature? That's a much more natural way to sign it than with a Provenance inside the document. If you want to sign with Provenance, it needs to be outside the document.
Lloyd McKenzie (Oct 25 2021 at 02:03):
Also, if you're capturing a Bundle signature, you don't have to worry about having a 'resource' to indicate the signing entity.
Corey Spears (Oct 25 2021 at 04:02):
That could work. Would we just extend the element with additional information such as the role being played by signing, any necessary credentials, and statements being attested to?
John Moehrke (Oct 25 2021 at 12:15):
I the Bundle.signature element is a datatype Signature, so it has those elements.
Corey Spears (Oct 25 2021 at 15:38):
I see the signature type, which can be used for the role I was mentioning, but I do not see anywhere to place credentials and the specific statement that they are agreeing to (each signer may have a different statement).
John Moehrke (Oct 25 2021 at 15:40):
statement? --- are you referring to the "meaning of my signature"? That would be the .type element.
John Moehrke (Oct 25 2021 at 15:41):
can you come to the FHIR-Security call (in 20 minutes) as it might be good for us to understand the use-case and need. This is likely some of the very first "Trial Use" that this datatype is receiving, so there might be major changes you might drive.
John Moehrke (Oct 25 2021 at 15:42):
https://confluence.hl7.org/display/SEC/2021-10-25+FHIR-Security+Meeting+Agenda
John Moehrke (Oct 25 2021 at 15:43):
we will likely be discussing a change to Signature datatype that @Josh Mandel has entered requesting relaxing cardinality.
Corey Spears (Oct 25 2021 at 16:54):
A couple of example:
image.png
image.png
image.png
John Moehrke (Oct 25 2021 at 17:30):
I would expect that each of those might have their own defined Code. That Code when used in a signature has that specific meaning.
Lloyd McKenzie (Oct 25 2021 at 18:47):
What is the 'document' in each of those cases? Some of them seem to be stand-alone statements with no document being necessary.
Corey Spears (Oct 25 2021 at 18:48):
These are narrative statement, so I would not expect them to be codified as they could be unique per form of document. Signature type is of datatype coding, so it would not even be possible to have a text (such as one could use with a CodeableConcept).
Corey Spears (Oct 25 2021 at 18:51):
These are from examples of Living Will and Durable Healthcare Power of Attorney documents. They generally show up at the bottom of the document.
https://www.wwmedgroup.com/wp-content/uploads/2015/12/advance-directive-forms.pdf
http://depts.washington.edu/hdcoe/wp-content/uploads/2020/04/WSMA-Advance-Directives-July-2019.pdf
https://www.hov.org/media/1112/living-will_forms.pdf
Lloyd McKenzie (Oct 25 2021 at 18:53):
Right, but why do you have a 'document' if all you have is a single statement?
Corey Spears (Oct 25 2021 at 19:02):
I am not sure I follow. Someone is signing the document to represent their interests (the primary content of the document), others are signing that they are a witness (or in some cases signing on behalf of another (such as guardian signing off for the subject). Each signer has a specific statement about their role and what explicitly they are attesting to in that signature.
Lloyd McKenzie (Oct 25 2021 at 19:08):
I'm saying that if you have a very short statement, using a FHIR document to represent it is sort of overkill.
Corey Spears (Oct 25 2021 at 23:17):
We are using a document for all of the data of which this is a small part. We don't want a separate document to just represent that statement (a statement which is part of a larger document).
Lloyd McKenzie (Oct 25 2021 at 23:25):
Ok, but if all you're signing is the statement, then that's not the same as signing the whole document. In that case, having the statement as a DocumentReference and a Provenance with the signature sitting inside the document is fully reasonable.
John Moehrke (Oct 26 2021 at 10:52):
I thought those "statements" were the meaning of the signature, that the content being signed was the document content. That is why I figured those "statements" were actually signature purpose codes.
Corey Spears (Oct 26 2021 at 12:58):
@John Moehrke, That seems like a good way to characterize it. The issue we run in to is that each form or instrument can be different and are often times dictated or guided by legal or regulatory requirements. They often can't be codified. If we had a more open way to express them than a code or set of codes, I think we would be closer.
John Moehrke (Oct 26 2021 at 13:00):
I am unclear on why a code can't be defined for each. You can define codes in your IG, others can define codes within their Domain. Each code does need to be understood by the parties involved... so, yes less codes is better than infinite number of codes. This is why there are a set of signature purpose codes that are very gross but effective.
Corey Spears (Oct 26 2021 at 13:23):
These are not settled scientific concepts. These human created statements written through legislation, regulation, or just because someone thought it was a good idea. There is no agreed upon method, that I know of, that these statement have to follow. Sure, we can say something is an author statement or a witness statement or a notary statement, but we can't codify what that statement says. They are unbounded.
Lloyd McKenzie (Oct 26 2021 at 13:44):
It only makes sense as a code on a signature of the document if the all the content in the document is pertinent to text. If you have a document with three different advanced directives, you can't have signatures at the document level to represent each.
Last updated: Apr 12 2022 at 19:14 UTC
