37 Document Digital Signature (DSG)

The Document Digital Signature (DSG) Profile defines general purpose methods of digitally signing of documents for communication and persistence. Among other uses, these methods can be used within an IHE Document Sharing Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD). There are three methods of digital signature defined here: Enveloping, Detached (manifest), and SubmissionSet.

• An Enveloping Signature is a Digital Signature Document that contains both the signature block and the content that is signed. Access to the contained content is through removing the Enveloping - Digital Signature. Among other uses, this method should not be used with Document Sharing infrastructure.
• A Detached Signature is a Digital Signature Document that contains a manifest that points at independently managed content. Detached signatures leave the signed document or documents in the original form. Among other uses, this method is recommended for use with a Document Sharing infrastructure to support Digital Signatures, as this method does not modify the original Document Content. This method uses the Document Sharing "SIGNS" relationship provides linkage.
• A SubmissionSet Signature is a Detached Signature Document that attests to the content in a SubmissionSet SubmissionSet by: containing a manifest of all the other Documents included in the SubmissionSet, and a reference to the SubmissionSet. The Document Sharing "SIGNS" relationship may be used but is not required.

Ink-on-paper signatures have been a part of the documentation process in health care and have traditionally been indicators of accountability. Reliable exchange and storage of electronic data between disparate systems requires a standard that implements equivalent non-repudiation to prevent document creators from denying authorship and rejecting responsibility.

37.1 DSG Actors/Transactions

This section defines the actors, transactions, and/or content modules in this profile.

Figure 37.1-1 shows the actors directly involved in the DSG Profile and the direction that the content is exchanged.

This profile defines only the capability for Document Digital Signature. This profile does not include transport, workflow, or other content profiles. The grouping of the content module described in this profile to specific actors is described in more detail in the "Required Actor Groupings" section below.

Table 37.1-1 lists the content module(s) defined in the DSG Profile. To claim support with this profile, an actor shall support all required content modules (labeled "R") and may support optional content modules (labeled "O"). The content module implemented will be indicated by the Options declared for the Actor. See section 37.2.

Table 37.1-1: DSG Profile - Actors and Content Modules

Actors	Content Modules	Optionality	Reference
Content Creator	Document Digital Signature	RO	ITI TF-3: 5.5
	Document Digital Signature in JSON	O	ITI TF-3: 5.10
Content Consumer	Document Digital Signature	RO	ITI TF-3: 5.5
	Document Digital Signature in JSON	O	ITI TF-3: 5.10

37.1.1 Actor Descriptions and Actor Profile Requirements

Most requirements are documented in Content Modules (Volume 3). This section documents any additional requirements on profile’s actors.

A Content Creator that conforms to this profile shall have the capability to create a digital signature document conforming to the Document Digital Signature content module using the signature option(s) chosen.

A Content Consumer that conforms to this profile shall have the capability to verify signatures using the signature option(s) chosen.

37.2 DSG Actor Options

Table 37.2-1 lists the option(s) defined in the DSG Profile.

Table 37.2-1: DSG Profile - Options

Actors	Option	Vol. & Section
Content Creator (Note 1)	Detached Signature	ITI TF-1: 37.2.1
	SubmissionSet Signature	ITI TF-1: 37.2.1.1
	Enveloping Signature	ITI TF-1: 37.2.2
	JSON Detached Signature	ITI TF-1: 37.2.3
	JSON Submission Set Signature	ITI TF-1: 37.2.3.1
	JSON Enveloping Signature	ITI TF-1: 37.2.4
Content Consumer (Note 1)	Detached Signature	ITI TF-1: 37.2.1
	SubmissionSet Signature	ITI TF-1: 37.2.1.1
	Enveloping Signature	ITI TF-1: 37.2.2
	JSON Detached Signature	ITI TF-1: 37.2.3
	JSON Submission Set Signature	ITI TF-1: 37.2.3.1
	JSON Enveloping Signature	ITI TF-1: 37.2.4

Note 1: Content Creator Actors and Content Consumer Actors shallSHALL support at least one option.

37.2.1 Detached Signature Option

Content Creators that support the Detached Signature Option shall have the capability to create a Detached Signature document that is composed of the XML Signature block as specified in ITI TF-3: 5.5.2 and 5.5.3ITI TF-3: 5.5.3, and a manifest of references to the signed documents. The signature document does not include the content of the documents that are signed. The Detached Signature Option supports the signing of multiple documents with one signature document.

The digital signature document, when published using Document Sharing Document Sharing profiles (e.g., XDS, XDR, XDM, XCA, etc.), shall conform to the Document Sharing metadata rules identified in ITI TF-3: 5.5.6.

Content Consumers that support the Detached Signature Option shall have the capability to perform signature verification specified in ITI TF-3: 5.5.5 for documents signed with a Detached Signature.

37.2.1.1 SubmissionSet Signature Option

The SubmissionSet Signature Option is a variant on the Detached Signature Option

The Content Creator shall have the ability to create a Detached Signature document that includes reference to all the documents included in the SubmissionSet, except for the Detached Signature document itself; and a reference to the SubmissionSet unique ID. This Detached Signature document is included in the SubmissionSet.

The SubmissionSet Signature Option requires the use of a Document Sharing Profile.

Content Consumers that support the SubmissionSet Signature Option shall have the capability to perform signature verification specified in ITI TF-3: 5.5.5 for all the documents contained within the Detached Signature.

37.2.2 Enveloping Signature Option

Content Creators that support the Enveloping Signature Option shall have the capability to create an Enveloping Signature document that is composed of the XML signature block as specified in ITI TF-3: 5.5.2 and 5.5.45.5.4, and the document that is signed. The Enveloping Signature Option only supports one document per signature document.

No guidance is given for use of Document Sharing with Enveloping Signatures. This is due to the fact that one document contains both signature and content; so it is unclear what the metadata should represent. XDS Affinity Domain or other Policy Domain may provide the guidance.

Content Consumers that support the Enveloping Signature Option shall have the capability to perform signature verification specified in ITI TF-3: 5.5.5 for documents signed with an Enveloping Signature.

37.2.3 JSON Detached Signature Option

Content Creators that support the JSON Detached Signature Option shall have the capability to create a Detached Signature document that is composed of the JWS JSON object as specified in ITI TF-3: 5.10.2 and ITI TF-3: 5.10.3, and a manifest of references to the signed documents. The signature document does not include the content of the documents that are signed. The JSON Detached Signature Option supports the signing of multiple documents with one signature document.

The digital signature document, when published using Document Sharing Document Sharing profiles (e.g., XDS, XCA, XDM, XDR, and MHD), shall conform to the Document Sharing metadata rules identified in ITI TF-3: 5.10.6 .

Content Consumers that support the JSON Detached Signature Option shall have the capability to perform signature verification specified in ITI TF-3: 5.10.5 for documents signed with a Detached Signature.

37.2.3.4 JSON SubmissionSet Signature Option

The JSON SubmissionSet Signature Option is a variant on the JSON Detached Signature Option.

The Content Creator shall have the ability to create a Detached Signature document that includes reference to all the documents included in the SubmissionSet, except for the Detached Signature document itself; and a reference to the SubmissionSet unique ID. This Detached Signature document is included in the SubmissionSet.

The JSON SubmissionSet Signature Option requires the use of a Document Sharing Profile.

Content Consumers that support the SubmissionSet Signature Option shall have the capability to perform signature verification specified in ITI TF-3: 5.10.5 for all the documents contained within the Detached Signature.

37.2.4 JSON Enveloping Signature Option

Content Creators that support the JSON Enveloping Signature Option shall have the capability to create an Enveloping Signature document that is composed of the JWS JSON object as specified in ITI TF-3: 5.10.2 and 5.10.4, and the document that is signed. The JSON Enveloping Signature Option only supports one document per signature document.

No guidance is given for use of Document Sharing with Enveloping Signatures. This is due to the fact that one document contains both signature and content; so it is unclear what the metadata should represent. XDS Affinity Domain or other Policy Domain may provide the guidance.

Content Consumers that support the JSON Enveloping Signature Option shall have the capability to perform signature verification specified in ITI TF-3: 5.10.5 for documents signed with an Enveloping Signature.

37.3 DSG Required Actor Groupings

There are two actors in this profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is not specifically addressed by this profile. This communication may be achieved by the Document Sharing profiles, or by other means.

When Digital Signature documents are stored using a Document Sharing profile, such as XDS, the metadata rules are defined in ITI TF-3: 5.5.6 for XML and in ITI TF-3: 5.10.6 for JSON.

Content Creator and Content Consumer are grouped with CT Time Client as Digital Signatures require a reliable date and time.

Content Creator and Content Consumer are grouped with ATNA Secure Node or Secure Application to record an Audit Message when a signature is created or validated.

Table 37.3-1: DSG - Required Actor Groupings

DSG Actor	Grouping Condition	Actor(s) to be grouped with	Reference	Content Bindings Reference
Content Creator	Required	CT / Time Client	ITI TF-1: 7.1	--
Content Creator	With the SubmissionSet Signature Option	XDS.b / Document Source (Note 1)	ITI TF-1: 10.1	--
		XDR / Document Source (Note 1)	ITI TF-1: 15.1	--
		XDM / Portable Media Creator (Note 1)	ITI TF-1: 16.1	--
		MHD / Mobile Health Documents (Note 1)	ITI TF-1: 33	--
Content Consumer	Required	CT / Time Client	ITI TF-1: 7.1	--
Content Consumer	with the SubmissionSet Signature Option	XDS.b / Document Consumer (Note 1)	ITI TF-1: 10.1	--
		XDR / Document Recipient (Note 1)	ITI TF-1: 15.1	--
		XDM / Portable Media Importer (Note 1)	ITI TF-1: 16.1	--
		MHD / Mobile Health Documents (Note 1)	ITI TF-1: 33	--

Note 1: One or more of the Document Sharing infrastructure groupings shall be supported.

Section 37.5 describes some optional groupings that may be of interest for security considerations and Section 37.6 describes some optional groupings in other related profiles.

37.4 Document Digital Signatures Profile Overview

The purpose of digital signatures in healthcare can vary greatly and it is important to understand the distinct use cases. A Digital Signature is a standards-based method to assure content integrity, authenticity, and authentication of the identity of the signer. The identity of the signer is assured through use of Private Key and Public Key management. Management of Private Key and Public Keys are not addressed by this profile. The date/time of when the signature happened is critical to proving the sequence of the data over time. For a discussion on Private Key and Public Key management (PKI), and assurance of time, see the Security Considerations section.

The outcome is a new Document (the signature). The Metadata for the signature document also has a signs relationship to the signed document(s). Figure 37.4-1 shows this relationship.

Figure 37.4-1: DSG Document and Signature Relationship

37.4.1 Verify Document Integrity

One purpose of use of a Digital Signature is to verify that the document being used is the same as the document that was signed and has not been modified by error or intent. This is called establishing document integrity. Document signatures may be used to establish document integrity; that is, to verify that the current document is the same as the signed document, and it has not been modified by error or intent. Document signatures may also be used to ascertain the identity of the signer and the reason for signing.

For example, to confirm that a document is a true copy of a source medical document, the digital signature is checked. If the signature is verified, then the document is a true copy. If the signature does not verify, then the document has been modified.

Another purpose of use is to verify the clinical content of a document. When a physician has verified that a report is complete and correct, the physician signs the document with purpose of signature being "verification". If there is ever a need, the digital signature provides a mechanism to show that the "verification" was attested to by the physician.

For example, a clinician who needs to rely on a document which was created by another clinician may use a signature to ascertain that the version they are using has been verified.

37.4.2 One Signature signing multiple documents

The Detached Signature Option supports a single signature document that simultaneously signs multiple documents. For example, when a doctor verifies and signs a diagnostic report, the digital signature can also sign the source data that was used to prepare the diagnostic report. The digital signature for a mammography diagnostic report may sign:

• The examination procedure notes
• The DICOM Mammography images that were read by the radiologist
• The verified diagnostic report

This signature indicates more than that the diagnostic report is complete and correct. It also indicates the data that was examined and can detect whether that data is subsequently modified or damaged. Further, it indicates the extent of the data used. If there are also other reports in the XDS Document Registry, e.g., a later lab report, the digital signature indicates that this other information not used to prepare the report.

37.4.2.1 Signing a SubmissionSet

A variant of a Signature signing multiple documents is one where the group of documents being signed is also defined by a Document Sharing SubmissionSet.

37.4.3 Processing by XDS Document Consumer

Among other uses, the Detached Signature Option supports use of Document Sharing Document Sharing infrastructure (e.g., XDS, XDR, XDM, and XCA) . The following sections describe how common queries can be performed in a Document Sharing environment where document digital signatures are used. Additional details about the Document Sharing infrastructure are described in the HIE Whitepaper

• Search for signatures, given a document

The signatures that apply to a specific document can be found by querying (e.g., the XDS Document Registry) to obtain the "SIGNS" association linkages to that specific document. The "SIGNS" associations link the Digital Signature documents with the documents signed.

• Search for documents, given a signature

The signature document itself contains a manifest that lists the document IDs for all of the signed documents. It might also contain a SubmissionSet uniqueId for a submission set. The documents can be obtained through the Document Sharing system. It is possible that authorization or other limits may prevent retrieval of some of these documents.

• Search for signatures

The signature documents are identified as a digital signature. This can be used to query for digital signatures in a time range, for specific patient, etc. The signature purpose codes can be used to limit these signatures. For example, a query may choose to eliminate data integrity signatures and search only for clinician signatures.

• Ignore signature documents in query

The digital signature type document can also be suppressed in queries that are intended to retrieve only source documents. In an environment with extensive use of data integrity, creation, verification, and other signatures there may be several signature documents for each source document. If signature documents are not suppressed then a query for clinical documents may also have distracting extra results returned for signatures.

37.4.4 Sign a document by Enveloping - Use Case Description

When a clinician needs to bind both a document and the signature into one document (for example, because there is no Document Sharing infrastructure to carry the document, the digital signature, and the association), then the Enveloping Signature Option needs to be used.

The Enveloping Signature method encapsulates the signed document inside of the digital signature document. The result is one new document that is externally the signature document, and embedded inside that document is the document that is signed.

Since it is unclear whether (or which) metadata should refer to the signed document or to the enveloping signature document, IHE does not specify metadata to be used for an Enveloping Signature document in a Document Sharing infrastructure.

37.4.5 Sign using both XML and JSON options

When the signer does not know which signature technology stack the validator is using, then the signer can choose to sign with both options; or the validator support both options

37.5 Security Considerations

Digital Signatures rely on a Private Key / Public Key Management Infrastructure (aka PKI) that must exist and be configured. The definition and configuration of PKI is outside the scope of this document content profile. PKI binds public keys with the respective identities of entities (like people and organizations). This binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). The PKI should adhere to ISO TS-17090 standards for PKI in healthcare.

The Detached Signature Option allows for independent management of signature document and content documents; thus, there is a risk they will be made unavailable through revision or access control.

Content Creator and Content Consumer shall be grouped with CT Time Client as Digital Signatures require a reliable date and time. There is a risk that the clock can be subverted, so operational controls should be used to audit clock modifications.

Content Creator implementing the JSON Detached Signature or the JSON Enveloping Signature Options shall have access to a Time Stamping Authority (TSA) Service that meets the JSON Signature tstVD requirement and local policy requirements for Time Stamping Authority.

Content Creator and Content Consumer should be grouped with ATNA Secure Node or Secure Application to record an Audit Message when a signature is created or validated.

37.6 Cross Profile Considerations

When used with a Document Sharing Document Sharing infrastructure (e.g., XDS, XDR, XDM, or XCA):

• ITI TF-3: 5.5.6 Document Sharing Metadata is used
• The "SIGNS" association type is used to indicate relationship between signed documents and the signature document

When no Document Sharing infrastructure is used, then the Enveloping Signature Option should be used.