IHE ITI TF Vol3

5.5Document Digital Signature (DSG) Document Content

Document Digital Signature content shall conform to XAdES schema for signatures, with extensions and restrictions defined in the following. IHE is not changing any optionality, prohibiting use of options, or mandating options. Issues such as long-term archival management of certificates are out of scope of this profile.

5.5.1 References

5.5.1.1 Normative References

[XAdES] : XML Advanced Electronic Signatures XAdES http://www.w3.org/TR/XAdES/ -- aka. ETSI TS 101 903

[W3C XMLDSIG] XML-Signature Syntax and Processing. W3C Recommendation. Donald Eastlake. June 2008. https://www.w3.org/TR/xmldsig-core/

[ASTM-E1762-05] ASTM E1762-95(2013) – Standard Guide for the Authentication of Health Care Information http://www.astm.org/cgi-bin/SoftCart.exe/STORE/filtrexx40.cgi?U+mystore+odvl4256+-L+ASTM:E1762+/usr6/htdocs/astm.org/DATABASE.CART/REDLINE_PAGES/E1762.htm

5.5.1.2 Informative References

[ASTM-E1985] E1985-98 -- Standard guide for user authentication and authorization http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/REDLINE_PAGES/E1985.htm?E+mystore

[ASTM-E2212] ASTM E2212 – Standard Practice for Healthcare Certificate Policy http://www.astm.org/cgi-bin/SoftCart.exe/STORE/filtrexx40.cgi?U+mystore+odvl4256+-L+ASTM:E2212+/usr6/htdocs/astm.org/DATABASE.CART/REDLINE_PAGES/E2212.htm

[ASTM-E2084] ASTM E2084 – Standard Specification for the Authentication of Healthcare Information using Digital Signatures http://www.astm.org/cgi-bin/SoftCart.exe/STORE/filtrexx40.cgi?U+mystore+odvl4256+-L+ASTM:E2084+/usr6/htdocs/astm.org/DATABASE.CART/REDLINE_PAGES/E2084.htm

[ISO17090] ISO/TS 17090-4 – Health Informatics – Public Key Infrastructure – Part 4: Digital Signatures for Healthcare Documents http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35489&ICS1=35&ICS2=240&ICS3=80

[ISO 21091] ISO/TS 21091- Health Informatics – Directory Services for Security, Communications, and Identification of Professionals and Patients http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35647&scopelist=PROGRAMME

[IETF RFC5280] IETF/RFC5280 – Internet X.509 Public Key Infrastructure and Certificate Revocation List (CRL) Profile https://datatracker.ietf.org/doc/rfc5280/

[ISO14533-2] ISO 14533-2:2012 – Process, data elements and documents in commerce, industry and administration – Long term signature profiles – Part 2: Long term signature profiles for XML Advanced Electronic Signatures (XAdES)

[ETSI TS 119 172-1] ETSI Technical Specifications 119 172-1 v1.1.1, Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 1: Building blocks and table of contents for human readable signature policy documents; Annex B: Commitment types. https://www.etsi.org/deliver/etsi_ts/119100_119199/11917201/01.01.01_60/ts_11917201v010101p.pdf

[ETSI TS 101 903] ETSI Technical Specifications 101 903, XML Advanced Electronic Signatures, Section 7.2.6, The CommitmentTypeIdentificationElement. http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf

[ETSI TS 101 733] ETSI Technical Specifications, commitment-type-indication Attribute 101 733, Electronic Signature and Infrastructures (ESI); CMS Advanced Electronic Signature (CAdES). https://www.etsi.org/deliver/etsi_ts/101700_101799/101733/02.02.01_60/ts_101733v020201p.pdf

5.5.2 Signature Specification

The following constraints define the Digital Signature block. This block is common to the detached signature and Enveloping signature.

Shall conform to XAdES-X-L – for support of Long Term signatures. The XAdES-X-L specification adds the timestamp of the signing and inclusion of the certificate and statement of revocation.

Shall use the hash algorithm sha256.
Shall use the canonicalization algorithm “Canonical XML 1.1 with Comments” ( http://www.w3.org/2006/12/xml-c14n11#WithComments ).
The policy may be identified as urn:ihe:iti:dsg:detached:2014 when the signature document is a Detached Signature and urn:ihe:iti:dsg:enveloping:2014 when the signature document is an Enveloping Signature to indicate that the signature document complies with the DSG Profile.

Shall include a “CommitmentTypeIndication” element for the Purpose(s) of Signature (aka purposeOfSignature). The Purpose can be the action being attested to, or the role associated with the signature. The value should come from ASTM E1762-95(2013) if applicable, and reproduced in Table 5.5.2-1. The coding scheme for ASTM is “1.2.840.10065.1.12”. Note that Content Creators and Content Consumers should be capable of being configured to other conformance policies to support local policy. For example , some environments may choose a different XAdES profile, hashing algorithm, policy identifier, or signature purpose vocabulary. Content Creators would thus create Digital Signature blocks that are not conformant to this profile. Content Consumers can validate these Digital Signature blocks, and be capable of configured behavior according to the local policy.

Some regions also require conformance to ISO 17090, which includes additional Certificate issuing, content, and validation rules.

Table 5.5.2-1: Digital Signature Purposes from ASTM E1762-95(2013)

Code	Term	Definition
1.2.840.10065.1.12.1.1	Author’s Signature	The signature of the primary or sole author of a health information document. There can be only one primary author of a health information document.
1.2.840.10065.1.12.1.2	Co-Author’s Signature	The signature of a health information document co-author. There can be multiple co-authors of a health information document.
1.2.840.10065.1.12.1.3	Co-participant’s Signature	The signature of an individual who is a participant in the health information document but is not an author or co-author. (e.g., a surgeon who is required by institutional, regulatory, or legal rules to sign an operative report, but who was not involved in the authorship of that report.)
1.2.840.10065.1.12.1.4	Transcriptionist/Recorder Signature	The signature of an individual who has transcribed a dictated document or recorded written text into a digital machine -readable format.
1.2.840.10065.1.12.1.5	Verification Signature	A signature verifying the information contained in a document. (e.g., a physician is required to countersign a verbal order that has previously been recorded in the medical record by a registered nurse who has carried out the verbal order.)
1.2.840.10065.1.12.1.6	Validation Signature	A signature validating a health information document for inclusion in the patient record. (e.g., a medical student or resident is credentialed to perform history or physical examinations and to write progress notes. The attending physician signs the history and physical examination to validate the entry for inclusion in the patient’s medical record.)
1.2.840.10065.1.12.1.7	Consent Signature	The signature of an individual consenting to what is described in a health information document.
1.2.840.10065.1.12.1.8	Signature Witness Signature	The signature of a witness to any other signature.
1.2.840.10065.1.12.1.9	Event Witness Signature	The signature of a witness to an event. (Example the witness has observed a procedure and is attesting to this fact.)
1.2.840.10065.1.12.1.10	Identity Witness Signature	The signature of an individual who has witnessed another individual who is known to them signing a document. (e.g., the identity witness is a notary public.)
1.2.840.10065.1.12.1.11	Consent Witness Signature	The signature of an individual who has witnessed the health care provider counselling a patient.
1.2.840.10065.1.12.1.12	Interpreter Signature	The signature of an individual who has translated health care information during an event or the obtaining of consent to a treatment.
1.2.840.10065.1.12.1.13	Review Signature	The signature of a person, device, or algorithm that has reviewed or filtered data for inclusion into the patient record. (e.g., (1) a medical records clerk who scans a document for inclusion in the medical record, enters header information, or catalogues and classifies the data, or a combination thereof; (2) a gateway that receives data from another computer system and interprets that data or changes its format, or both, before entering it into the patient record.)
1.2.840.10065.1.12.1.14	Source Signature	The signature of an automated data source. (e.g., (1) the signature for an image that is generated by a device for inclusion in the patient record; (2) the signature for an ECG derived by an ECG system for inclusion in the patient record; (3) the data from a biomedical monitoring device or system that is for inclusion in the patient record.)
1.2.840.10065.1.12.1.15	Addendum Signature	The signature on a new amended document of an individual who has corrected, edited, or amended an original health information document. An addendum signature can either be a signature type or a signature sub-type (see ASTM E1762-Section 8.1). Any document with an addendum signature shall have a companion document that is the original document with its original, unaltered content, and original signatures. The original document shall be referenced via an attribute in the new document, which contains, for example, the digest of the old document. Whether the original, unaltered, document is always displayed with the addended document is a local matter, but the original, unaltered, document must remain as part of the patient record and be retrievable on demand.
1.2.840.10065.1.12.1.16	Modification Signature	The signature on an original document of an individual who has generated a new amended document. This (original) document shall reference the new document via an additional signature purpose. This is the inverse of an addendum signature and provides a pointer from the original to the amended document.
1.2.840.10065.1.12.1.17	Administrative (Error/Edit) Signature	The signature of an individual who is certifying that the document is invalidated by an error(s), or is placed in the wrong chart. An administrative (error/edit) signature must include an addendum to the document and therefore shall have an addendum signature sub-type (see ASTM E1762-Section 8.1). This signature is reserved for the highest health information system administrative classification, since it is a statement that the entire document is invalidated by the error and that the document should no longer be used for patient care, although for legal reasons the document must remain part of the permanent patient record.
1.2.840.10065.1.12.1.18	Timestamp Signature	The signature by an entity or device trusted to provide accurate timestamps. This timestamp might be provided, for example, in the signature time attribute.

5.5.3 Detached Signature

The Detached Signature utilizes the XML Signature - Reference element (ds:reference) to identify and provide a hash for each document that is signed. This set of Reference elements is considered the manifest. The URI attribute shall be used and hold the document uniqueID. For documents that do not use a URI as the uniqueId, the Affinity Domain should determine an appropriate way to encode the DocumentEntry.uniqueId.

5.5.3.1 SubmissionSet Signature

The SubmissionSet Signature is a variant of the Detached Signature used to digitally sign a complete SubmissionSet. The signature can later be validated to assure that the SubmissionSet is complete and the same as when it was created.

The SubmissionSet Signature shall be a Detached Signature that has Reference elements for:

the SubmissionSet uniqueID with a hash value of “0”
the document uniqueID for each of the documents contained in the SubmissionSet not including the SubmissionSet Signature document

The SubmissionSet Signature creation is informatively described here with the Content Creator grouped with an XDS Document Source and is equally applicable with grouping the Content Creator with the other Document Sharing infrastructure (e.g., XDR, and XDM). The document publication transaction is not specific to the SubmissionSet Signature process or content, and is included here only to show overall workflow.

Informative process for creating a SubmissionSet Signature:

A set (n) of Documents of interest are gathered, or generated to be published
A SubmissionSet is created for the Documents, for example in preparation for using the Provide and Register Document Set-b [ITI-41] transaction or equivalent
A Digital Signature document is created which includes Reference elements of:

The SubmissionSet.uniqueId is included in the manifest, with a zero hash value (the value “0”).
All of the (n) documents to be included in the SubmissionSet, other than the signature document, are listed in the manifest with their hash.
The signature document is processed according to Section 5.5.2, and thus signed.

The signature document would be added to the SubmissionSet according to Section 5.5.6. The SubmissionSet may, but is not required, include all the “SIGNS” association defined in Section 5.5.6.4 with associations to all the other documents in the SubmissionSet. The “SIGNS” association is redundant in this case as the SubmissionSet already groups these documents.
The SubmissionSet with the (n) documents and the Digital Signature document is submitted using the Provide and Register Document Set-b [ITI-41] transaction, or equivalent from the other Document Sharing infrastructures.

5.5.4 Enveloping Signature

The Enveloping Signature utilizes the XML Signature – “Include” capability where the full content of the signed document is encoded inside the signature document in the Object element (ds:object).

The signed document shall be base64 encoded, unless some other policy overrides.

The object element Encoding shall be specified (http://www.w3.org/2000/09/xmldsig#base64).

5.5.5 Signature Verification

There are three levels of signature verification:

verifying that the Digital Signature block itself has integrity through verifying the signature across the XML-Signature,
confirming that the signer was authentic, not revoked, and appropriate to the signature purpose,
confirming that the signed Documents of interest are unmodified using the hash algorithm.

The Content Consumer shall verify the Digital Signature block has integrity.

The Content Consumer shall be able to be configured with local policy on PKI trust models, and management that supports the confirmation that the signer was authentic, not revoked, and appropriate to the signature purpose. The Content Consumer shall use this configuration when confirming the validity of the signature.

The Content Consumer shall be able to confirm the validity of the documents that are signed.

Workflow or local policy may direct that all or a subset of the signed documents be validated. There are use cases where only one document within a signed set of documents is all that is called for by the workflow.
Workflow or local policy may direct that all or a subset of the signatures found within a Digital Signature Document be validated. The Digital Signature Document may contain signatures for purposes that are not relevant to the Content Consumer purpose that may not be possible to fully validate. A Content Consumer should silently ignore signatures that are not necessary to the purpose of the Content Consumer. For example, a signature may be from a different organization.
The document may not be accessible to the user, for example authorization denied, so confirmation of valid signed content may be impossible.
If there is a SubmissionSet unique ID included in the manifest, then the Content Consumer shall be able to verify that the submission set reference in the manifest is the one containing the documents which are listed in the manifest and the documents listed in the manifest are the complete list of documents in the submission set on the XDS Registry.

The decision on what degree of verification is needed is determined by the application and use case.

The Content Consumer shall be able to validate content that uses SHA256 as well as SHA1.

5.5.6 Document Sharing Metadata

This section applies when the Content Creator or Content Consumer is utilizing a Document Sharing Profile for transport. This section defines the source for all required Document Sharing attributes and as many optional attributes as makes sense for implementers’ applications.

5.5.6.1 Document Sharing – DocumentEntry Metadata

The Signature Document shall have a compliant DocumentEntry with the following constraints:

5.5.6.1.1 XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode shall be urn:ihe:iti:dsg:detached:2014 when the signature document is a Detached Signature and urn:ihe:iti:dsg:enveloping:2014 when the signature document is an Enveloping Signature. The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3 .

5.5.6.1.2 XDSDocumentEntry.classCode

The classCode value will be a value representing the high-level classification of Digital Signature type documents within the XDS Affinity Domain or Community.

5.5.6.1.3 XDSDocumentEntry.typeCode

Where policy does not define a workflow specific typeCode, the following code should be used:

Coding schema = “ASTM”

Code value = “E1762”

Code value display name = “Full Document”

5.5.6.1.4 XDSDocumentEntry.author

The author should represent the signer.

5.5.6.1.5 XDSDocumentEntry.eventCodeList

The eventCodeList shall contain the signature Purpose(s) from the Digital Signature block “CommitmentTypeIndication” element, using Table 5.5.2-1.

5.5.6.1.6 XDSDocumentEntry.mimeType

Shall be “text/xml”

5.5.6.1.7 XDSDocumentEntry.title

Should be the same as the display name for the signature purpose

5.5.6.1.8 XDSDocumentEntry.language

The language of the signature content shall be ‘art’ as in “artificial”.

5.5.6.2 Document Sharing – SubmissionSet Metadata

This document content profile makes no changes to the structure of Submission Sets.

5.5.6.3 Document Sharing - Folder Metadata

This document content profile makes no changes to the structure of Folders.

5.5.6.4 Document Associations

When Detached Signature Option is used, the Content Creator shall use the “SIGNS” associationType Document Relationship to associate the signature (sourceObject) to the documents that it signs (targetObjects). See Section 4.2.2.

When SubmissionSet Signature Option is used, the Content Creator may use the “SIGNS” associationType Document Relationship to associate the signature (sourceObject) to the documents that it signs (targetObjects). See Section 4.2.2.

5.5.7 Security Considerations

See XAdES specification for risk assessment and mitigation plan on Digital Signatures.

5.5.7.1 Content Creator

When a Content Creator is grouped with an ATNA Secure Node or Secure Application, it shall create an Audit Message indicating the Signature Creation event.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(113031, DCM, “Signed Manifest”)
	EventActionCode	M	“C” (Create)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“urn:ihe:iti:dsg”, “IHE Transactions”, “Document Digital Signature”)
Audit Source (Content Consumer) (1)
ActiveParticipant (User/System that requested Signature Creation) (0..n)
ActiveParticipant (Patient indicated in the Signature Document) (0..n)
ParticipantObjectIdentification (Digital Signature Document) (1)

5.5.7.2 Content Consumer

When a Content Consumer is grouped with an ATNA Secure Node or Secure Application, it shall create an Audit Message indicating the Signature Verification event.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110007, DCM, “Report Verification”)
	EventActionCode	M	“R” (Read)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“urn:ihe:iti:dsg”, “IHE Transactions”, “Document Digital Signature”)
Audit Source (Content Consumer) (1)
ActiveParticipant (User/System that requested Signature Validation) (0..n)
ActiveParticipant (Patient indicated in the Signature Document) (0..n)
ParticipantObjectIdentification (Digital Signature Document) (1)