-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathch-5.10.html
446 lines (440 loc) · 29.4 KB
/
ch-5.10.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
<!doctype html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en_US">
<head>
<meta xmlns="" charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title xmlns="">IHE ITI TF Vol3</title>
<link xmlns="" rel="stylesheet" href="../../../css/styles.css" />
<script type="text/javascript" src="https://www.googletagmanager.com/gtag/js?id=G-HLBNC861DJ" async> </script>
</head>
<body xmlns="">
<header>
<div class="title-bar" data-responsive-toggle="responsive-menu" data-hide-for="medium">
<button class="menu-icon" type="button" data-toggle="responsive-menu"></button>
<div class="title-bar-title">IHE ITI Technical Framework</div>
</div>
<div class="top-bar" id="responsive-menu">
<div class="top-bar-left">
<img src="../../../IHE_INTERNATIONAL.png" class="IHE logo hide-for-small-only" alt="IHE logo" />
<ul id="tf-small-menu" class="menu vertical show-for-small-only">
<li><a class="ihe-purple" href="https://ihe.net" target="_blank">About IHE</a></li>
<li class="menu-text">Sections
<ul id="tf-small-menu-list" class="nested vertical menu">
</ul>
</li>
</ul>
</div>
<div class="top-bar-right hide-for-small-only">
<ul class="menu">
<li class="menu-text tf-version">IHE IT Infrastructure (ITI) Technical Framework, Volume <span id="volumeNo"></span><br />Revision 20.0, August 4, 2023 – Final Text</li>
</ul>
<ul class="menu align-right">
<li><input id="ihe-search-field" type="search" placeholder="Search"></li>
<li><button id="ihe-search-button" type="button" class="button search">Search</button></li>
</ul>
</div>
</div>
</header>
<div class="navigation">
<nav aria-label="You are here:" role="navigation">
<ul class="breadcrumbs">
</ul>
</nav>
</div>
<div class="scroll-top-wrapper">
<span class="scroll-top-inner">
<i class="size-icon-lg fi-arrow-up"></i>
</span>
</div>
<div class="grid-container fluid">
<div class="grid-x grid-margin-x align-center">
<div class="cell medium-11">
<div class="callout warning">
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the <a href=https://profiles.ihe.net/ITI/TF/Volume1/index.html>Volume 1 Table of Contents</a>.
</div>
</div>
</div>
<main>
<div class="grid-x grid-margin-x align-center">
<div class="hide-for-small-only cell medium-2 large-2" data-sticky-container>
<div id="section-menu" class="sticky" data-sticky data-anchor="main-top">
</div>
</div>
<div id="main-top" class="cell medium-10 large-10">
<h2 id="5.10">5.10 Document Digital Signature (DSG) JSON Signature Document Content</h2>
<p>Document Digital Signature content SHALL conform to JAdES 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. If there is a conflict in the requirements specified here versus as specified in JAdES, then the JAdES specification shall be considered as authoritative.</p>
<h3 id="5.10.1">5.10.1 References</h3>
<h4 id="5.10.1.1">5.10.1.1 Normative References</h4>
<p>
<span style="font-weight:bold">[RFC 7515]</span>
<span>JSON Web Signature (JWS)</span>
<a href="https://tools.ietf.org/html/rfc7515">https://tools.ietf.org/html/rfc7515</a>
<span />
</p>
<p>
<span style="font-weight:bold">[JAdES]</span>
<span>JSON Advanced Electronic Signatures JAdES</span>
<a href="https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf">https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf</a>
<span> -- aka. ETSI TS 119 182-1</span>
</p>
<p>
<span style="font-weight:bold">[RFC 7797]</span>
<span>JSON Web Signature (JWS) Unencoded Payload Option</span>
<a href="https://tools.ietf.org/html/rfc7797">https://tools.ietf.org/html/rfc7797</a>
<span />
</p>
<p>
<span style="font-weight:bold">[RFC 7518]</span>
<span>JSON Web Algorithms (JWA)</span>
<a href="https://tools.ietf.org/html/rfc7518">https://tools.ietf.org/html/rfc7518</a>
<span />
</p>
<p>
<span style="font-weight:bold">[ETSI TS 119 312]</span>
<span>Electronic Signatures and Infrastructures (ESI); Cryptographic Suites</span>
<a href="https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf">https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf</a>
<span />
</p>
<h4 id="5.10.1.2">5.10.1.2 Informative References</h4>
<p>
<span style="font-weight:bold">[ASTM-E1762-05]</span>
<span>ASTM E1762-95(2013) – Standard Guide for the Authentication of Health Care Information</span>
<span />
</p>
<p>
<span style="font-weight:bold">[ETSI TS 119 511]</span>
<span>Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques</span>
<a href="https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.01.01_60/ts_119511v010101p.pdf">https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.01.01_60/ts_119511v010101p.pdf</a>
<span />
</p>
<p>
<span style="font-weight:bold">[ETSI ES 201 733]</span>
<span>Electronic Signatures Formats</span>
<a href="https://www.etsi.org/deliver/etsi_es/201700_201799/201733/01.01.02_50/es_201733v010102m.pdf">https://www.etsi.org/deliver/etsi_es/201700_201799/201733/01.01.02_50/es_201733v010102m.pdf</a>
<span />
</p>
<h3 id="5.10.2">5.10.2 JSON Signature Specification</h3>
<p>The following constraints define the <a href="https://datatracker.ietf.org/doc/html/rfc7515#section-3.2">JWS JSON</a> object. This block is common to the Detached signature and Enveloping signature.</p>
<ul>
<li class="bullet-list1">SHALL use JSON Web Signature (JWS)(see <a href="https://tools.ietf.org/html/rfc7515">RFC 7515</a>). JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Hash-based Message Authentication Codes (HMACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA).</li>
<li class="bullet-list1">The JWS SHALL be represented as a JSON object which uses JWS JSON serialization as specified in <a href="https://tools.ietf.org/html/rfc7515">RFC 7515.</a></li>
<li class="bullet-list1">SHALL conform to JAdES-B-LT – for support of Long Term signatures. The JAdES-B-LT specification adds the timestamp of the signing, inclusion of the signing certificate and statement of revocation.</li>
</ul>
<h4 id="5.10.2.1">5.10.2.1 Protected Header</h4>
<h5 id ="5.10.2.1.1">5.10.2.1.1 "alg" (Algorithm) Header Parameter</h5>
<ul>
<li class="bullet-list1">SHALL be present.</li>
<li> It is recommend to use algorithms as specified in <a href="https://www.rfc-editor.org/rfc/rfc7518.html#section-3.1">RFC 7518</a> and <a href="https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.01.01_60/ts_119312v010101p.pdf">ETSI TS 119 312.</a></li>
<li>RS256 algorithm SHALL be implemented for the purpose of interoperability testing. However, implementors SHOULD take into account additional considerations such as jurisdictional policies, quantum safe computing, and evolving guidance from RFC 7518 and ETSI TS 119 312.</li>
</ul>
<h5 id="5.10.2.1.2">5.10.2.1.2 "kid" (key identifier) Parameter</h5>
<ul>
<li>The kid parameter, if present, is a hint indicating which key was used to secure the JWS. The kid claim is used by DSG Content Consumers for looking up the public key for verification of digital signatures.</li>
</ul>
<h5 id="5.10.2.1.3">5.10.2.1.3 "crit" (critical) Parameter</h5>
<ul>
<li>The header SHALL include the crit header parameter and conform to specifications as per JAdES</li>
</ul>
<h5 id="5.10.2.1.4">5.10.2.1.4 "sigT" (claimed signing Time) Parameter</h5>
<ul>
<li>The header SHALL include the sigT header parameter and conform to specifications as per IHE Consistent Time (CT) profile</li>
</ul>
<h5 id="5.10.2.1.5">5.10.2.1.5 Certificate Digest</h5>
<ul>
<li>SHALL have at least one of the following header parameters in its JWS Protected Header: x5t#S256 (specified in clause 4.1.8 of IETF RFC 7515), x5c (specified in clause 4.1.6 of IETF RFC 7515), sigX5ts (specified in clause 5.2.2.3 of the JAdES specification), or x5t#o (specified in clause 5.2.2 of the JAdES Specification).</li>
</ul>
<h5 id="5.10.2.1.6">5.10.2.1.6 "srCms" (signer commitments) Header Parameter</h5>
<ul><li class="bullet-list1">The Signature SHALL include a "srCms signer commitments" element for the Purpose(s) of Signature. The Purpose can be the action being attested to, or the role associated with the signature. The value shall come from <a href = "http://hl7.org/fhir/ValueSet/signature-type">Signature type ValueSet</a> as defined in FHIR.</li></ul>
<h5 id="5.10.2.1.7">5.10.2.1.7 "sigPId" (signature Policy Identifier) Header Parameter</h5>
<ul>
<li class="bullet-list1">
<span>The policy may be identified in the sigPId header parameter as</span>
<span style="font-weight:bold">urn:ihe:iti:dsg:detached:2014</span>
<span>when the signature document is a Detached Signature and</span>
<span style="font-weight:bold">urn:ihe:iti:dsg:enveloping:2014</span>
<span>when the signature document is an Enveloping Signature to indicate that the signature document complies with the DSG Profile.</span></li>
</ul>
<h4 id = 5.10.2.2>5.10.2.2 Unprotected Header</h4>
<h5 id="5.10.2.2.1">5.10.2.2.1 "etsiU" Unprotected Header Parameter</h5>
<ul>
<li class="bullet-list1">The etsiU parameter SHALL be present in the unprotected header as per the JAdES specification</li>
<li>The etsiU header parameter SHALL be the only header parameter incorporated to the JWS Unprotected Header</li>
</ul>
<h5 id="5.10.2.2.2">5.10.2.2.2 "sigTst" JSON object</h5>
<ul>
<li class="bullet-list1">The sigTst parameter SHALL be present in the unprotected header as per the JAdES specification</li>
</ul>
<h4 id="5.10.2.3">5.10.2.3 Payload</h4>
<ul><li class="bullet-list1">See the Payload sections within Detached (<a href="5.10.3.3">section 5.10.3.3</a>) and within Enveloping (<a href="5.10.4.3">section 5.10.4.3</a>) for specific guidance</li></ul>
<h4 id="5.10.2.4">5.10.2.4 Signature</h4>
<ul><li class="bullet-list1">The Signature SHALL use the algorithm in the <a href="5.10.2.1.1">5.10.2.1.1</a> alg parameter section above.</li>
</ul>
<h3 id="5.10.3">5.10.3 JSON Detached Signature</h3>
<h4 id="5.10.3.1">5.10.3.1 Protected Header</h4>
<h5 id="5.10.3.1.1">5.10.3.1.1 "sigD" Header Parameter</h5>
<ul>
<li>The sigD parameter SHALL be included as per 5.2.8.1 of the JAdES Specification.</li>
<li>The mID member SHALL be present and set to "http://uri.etsi.org/19182/ObjectIdByURIHash"<sup>1</sup>.</li>
<li>The pars member SHALL be an array of strings that contain references to each data object<sup>2</sup> being signed. This array is considered the manifest of the data objects being signed. Each string in this array shall be a URI. See <a href="5.10.6.1.9">Section 5.10.6.1.9</a> for more details.</li>
<li>The hashV, and the hashM members SHALL be present.</li>
<li>The ctys member SHALL be present.</li>
</ul>
<p class="note">1: For minimal interoperability and to claim conformance to IHE-DSG, the recommendation is to use the objectIdByURIHash mechanism given performance and consistency reasons, as signatures may need to be calculated on low compute devices and in distributed systems, URIs can change due to network restructuring or other factors. A hash can provide a consistent identifier that remains the same even if the underlying URI changes.
</p>
<p class="note">2: Data Objects refer to the binary representations of documents or any other content on which the digital signature is captured and verified</p>
<h5 id="5.10.3.1.2">5.10.3.1.2 "cty" (content type) Header Parameter</h5>
<ul><li>SHALL NOT be included</li></ul>
<h4 id="5.10.3.2">5.10.3.2 Unprotected Header</h4>
<ul><li>No additional considerations other than the ones specified in the section <a href="5.10.2.2">5.10.2.2</a></li></ul>
<h4 id="5.10.3.3">5.10.3.3 Payload</h4>
<ul><li>The Detached Signature is accomplished by deleting the "payload" member of the JWS JSON Object</li></ul>
<h4 id="5.10.3.4">5.10.3.4 Signature</h4>
<ul><li>As per section 5.2.8.3.3 of JAdES, the JWS Payload SHALL contribute shall contribute as an empty stream to the computation of the JWS Signature Value.</a></li></ul>
<h4 id="5.10.3.5">5.10.3.5 JSON SubmissionSet Signature</h4>
<p>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 references for:</p>
<ul>
<li>the SubmissionSet uniqueId as per <a href="5.10.3.5.1">5.10.3.5.1 "iheSSId" (SubmissionSet uniqueId) Header Parameter</a></li>
<li>the document uniqueId for each of the documents contained in the SubmissionSet not including the SubmissionSet Signature document within the manifest as per <a href="5.10.3.1.1">above section</a></li>
</ul>
<p>
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. 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:
</p>
<ol>
<li>A set (n) of Documents of interest are gathered, or generated to be published.</li>
<li>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.</li>
<li>
A Digital Signature document is created which includes reference of:</li>
<ol type="i">
<li>The SubmissionSet.uniqueId is included in the iheSSId header parameter.</li>
<li>All of the (n) documents to be included in the SubmissionSet, other than the signature document, are listed in the manifest.</li>
<li>The signature document is processed according to <a href="5.10.3">Section 5.10.3</a>, and thus signed.</li>
</ol>
</li>
<li>The signature document would be added to the SubmissionSet according to <a href="5.10.6">Section 5.10.6</a>. The SubmissionSet may, but is not required, include all the “SIGNS” association defined in <a href="5.10.6.4">Section 5.10.6.4</a> 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.</li>
<li>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.</li>
</ol>
<h5 id="5.10.3.5.1">5.10.3.5.1 "iheSSId" (SubmissionSet uniqueId) Header Parameter</h4>
<p><b>Semantics</b></p>
<p>The iheSSId header parameter shall be a new signed (protected) header parameter that qualifies the signature.</br></br>
The iheSSId header parameter's value shall specify the SubmissionSet uniqueId as per the <a href="https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.3.3.12">4.2.3.3.12 SubmissionSet.uniqueId</a>
</p>
<p><b>Syntax</b></p>
<p>The iheSSId header parameter is defined below:</br></br>
"iheSSId" : {"type":"string","format":"oid"}. </br></br>
<b>Note:</b> The <a href="5.10.2.1.3">crit</a> header parameter shall include the "iheSSId" extension header parameter when the SubmissionSet Option is used.
</p>
<h3 id="5.10.4">5.10.4 JSON Enveloping Signature</h3>
<h4 id="5.10.4.1">5.10.4.1 Protected Header</h4>
<h5 id="5.10.4.1.1">5.10.4.1.1 "cty" (content type) Header Parameter</h5>
<ul><li>SHALL be included as per syntax specified in IETF RFC 7515, clause 4.1.10</li></ul>
<h4 id="5.10.4.2">5.10.4.2 Unprotected Header</h4>
<ul><li>No additional considerations other than the ones specified in the section <a href="5.10.2.2">5.10.2.2</a></li></ul>
<h4 id="5.10.4.3">5.10.4.3 Payload</h4>
<ul><li> When FHIR Resources are signed, the signature is across the BASE64URL(JWS Payload) form of the Payload. The DSGj profile does not create any additional expectations of transformation on the Payload of any form.</li></ul>
<h4 id="5.10.4.4">5.10.4.4 Signature</h4>
<ul><li>No additional considerations other than the ones specified in the section <a href="5.10.2.4">5.10.2.4</a></li></ul>
<h3 id="5.10.5">5.10.5 JSON Signature Verification</h3>
<p>There are three levels of signature verification:</p>
<ol>
<li class="numbered-list1">verifying that the JWS JSON object itself has integrity through verifying the signature,</li>
<li class="numbered-list1">confirming that the signer was authentic, not revoked, and appropriate to the signature purpose, and</li>
<li class="numbered-list1">confirming that the signed Documents of interest are unmodified using the hash algorithm.</li>
</ol>
<p>The Content Consumer SHALL verify the JWS JSON object has integrity.</p>
<p>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.</p>
<p>The Content Consumer SHALL be able to confirm the validity of the documents that are signed.</p>
<ul>
<li class="bullet-list1">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.</li>
<li class="bullet-list1">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.</li>
<li class="bullet-list1">The document may not be accessible to the user, for example authorization denied, so confirmation of valid signed content may be impossible.</li>
</ul>
<p>The decision on what degree of verification is needed is determined by the application and use case.</p>
<p>The Content Consumer SHALL be able to validate content that uses SHA256.</p>
<h3 id="5.10.6">5.10.6 JSON Document Sharing Metadata</h3>
<p>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.</p>
<h4 id="5.10.6.1">5.10.6.1 Document Sharing – DocumentEntry Metadata</h4>
<p>The Signature Document SHALL have a compliant DocumentEntry with the following constraints:</p>
<h5 id="5.10.6.1.1">5.10.6.1.1 XDSDocumentEntry.formatCode</h5>
<p>
<span>The XDSDocumentEntry.formatCode SHALL be</span>
<span style="font-weight:bold">urn:ihe:iti:dsg:detached:2014</span>
<span>when the signature document is a Detached Signature and</span>
<span style="font-weight:bold">urn:ihe:iti:dsg:enveloping:2014</span>
<span>when the signature document is an Enveloping Signature. The formatCode codeSystem SHALL be</span>
<span style="font-weight:bold">1.3.6.1.4.1.19376.1.2.3</span>.
<span>.</span>
</p>
<h5 id="5.10.6.1.2">5.10.6.1.2 XDSDocumentEntry.classCode</h5>
<p>The classCode value SHALL be a value representing the high-level classification of Digital Signature type documents within the XDS Affinity Domain or Community.</p>
<h5 id="5.10.6.1.3">5.10.6.1.3 XDSDocumentEntry.typeCode</h5>
<p>Where policy does not define a workflow specific typeCode, the following code SHOULD be used:</p>
<p>Coding schema = "ASTM"</p>
<p>Code value = "E1762"</p>
<p>Code value display name = "Full Document"</p>
<h5 id="5.10.6.1.4">5.10.6.1.4 XDSDocumentEntry.author</h5>
<p>The author SHOULD represent the signer.</p>
<h5 id="5.10.6.1.5">5.10.6.1.5 XDSDocumentEntry.eventCodeList</h5>
<p>The eventCodeList SHALL contain the signature Purpose(s) from the Protected Header's "srCms signer commitments" element, using the <a href = "http://hl7.org/fhir/ValueSet/signature-type">Signature type ValueSet</a></p>
<h5 id="5.10.6.1.6">5.10.6.1.6 XDSDocumentEntry.mimeType</h5>
<p>SHALL be "application/json"</p>
<h5 id="5.10.6.1.7">5.10.6.1.7 XDSDocumentEntry.title</h5>
<p>SHOULD be the same as the display name for the signature purpose</p>
<h5 id="5.10.6.1.8">5.10.6.1.8 XDSDocumentEntry.language</h5>
<p>The language of the signature content SHALL be ‘art’ as in "artificial".</p>
<h5 id ="5.10.6.1.9">5.10.6.1.9 XDSDocumentEntry.uniqueId</h5>
<p>
SHALL use a URI format to 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. See ebRIM Representation <a href="https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.3.2.26">Section 4.2.3.2.26</a></p>
<h4 id="5.10.6.3">5.10.6.3 Document Sharing - Folder Metadata</h4>
<p>This document content profile makes no changes to the structure of Folders.</p>
<h4 id="5.10.6.4">5.10.6.4 Document Associations</h4>
<p>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 ebRIM Representation <a href="https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.2">Section 4.2.2</a>.</p>
<h3 id="5.10.7">5.10.7 Security Considerations</h3>
<p>See ETSI ES 201 733 and ETSI TS 119 511 specifications for risk assessment and mitigation plan on Digital Signatures. Note that Content Creators and Content Consumers SHOULD be capable of being configured to other conformance policies to support other jurisdictional policies.</p>
<h4 id="5.10.7.1">5.10.7.1 Content Creator</h4>
<p>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.</p>
<table cellspacing="0" cellpadding="0">
<tr>
<td>
<div />
</td>
<td class="tableHeader">Field Name</td>
<td class="tableHeader">Opt</td>
<td class="tableHeader">Value Constraints</td>
</tr>
<tr>
<td rowspan="5">
<p>Event</p>
<p>
<span style="font-weight:bold">AuditMessage/</span>
<br />
<span style="font-weight:bold">EventIdentification</span>
</p>
</td>
<td>EventID</td>
<td>M</td>
<td>EV(113031, DCM, "Signed Manifest")</td>
</tr>
<tr>
<td>EventActionCode</td>
<td>M</td>
<td>"C" (Create)</td>
</tr>
<tr>
<td>EventDateTime</td>
<td>M</td>
<td>not specialized</td>
</tr>
<tr>
<td>EventOutcomeIndicator</td>
<td>M</td>
<td>not specialized</td>
</tr>
<tr>
<td>EventTypeCode</td>
<td>M</td>
<td>EV("urn:ihe:iti:dsg", "IHE Transactions", "Document Digital Signature")</td>
</tr>
<tr>
<td colspan="4">Audit Source (Content Consumer) (1)</td>
</tr>
<tr>
<td colspan="4">ActiveParticipant (User/System that requested Signature Creation) (0..n)</td>
</tr>
<tr>
<td colspan="4">ActiveParticipant (Patient indicated in the Signature Document) (0..n)</td>
</tr>
<tr>
<td colspan="4">ParticipantObjectIdentification (Digital Signature Document) (1)</td>
</tr>
</table>
<h4 id="5.10.7.2">5.10.7.2 Content Consumer</h4>
<p>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.</p>
<table cellspacing="0" cellpadding="0">
<tr>
<td>
<div />
</td>
<td class="tableHeader">Field Name</td>
<td class="tableHeader">Opt</td>
<td class="tableHeader">Value Constraints</td>
</tr>
<tr>
<td rowspan="5">
<p>Event</p>
<p>
<span style="font-weight:bold">AuditMessage/</span>
<br />
<span style="font-weight:bold">EventIdentification</span>
</p>
</td>
<td>EventID</td>
<td>M</td>
<td>EV(110007, DCM, "Report Verification")</td>
</tr>
<tr>
<td>EventActionCode</td>
<td>M</td>
<td>"R" (Read)</td>
</tr>
<tr>
<td>EventDateTime</td>
<td>M</td>
<td>not specialized</td>
</tr>
<tr>
<td>EventOutcomeIndicator</td>
<td>M</td>
<td>not specialized</td>
</tr>
<tr>
<td>EventTypeCode</td>
<td>M</td>
<td>EV("urn:ihe:iti:dsg", "IHE Transactions", "Document Digital Signature")</td>
</tr>
<tr>
<td colspan="4">Audit Source (Content Consumer) (1)</td>
</tr>
<tr>
<td colspan="4">ActiveParticipant (User/System that requested Signature Validation) (0..n)</td>
</tr>
<tr>
<td colspan="4">ActiveParticipant (Patient indicated in the Signature Document) (0..n)</td>
</tr>
<tr>
<td colspan="4">ParticipantObjectIdentification (Digital Signature Document) (1)</td>
</tr>
</table>
</div>
</main>
</div>
<footer class="ihe-footer">
<div class="grid-container fluid">
<div class="grid-x grid-margin-x align-middle">
<div class="cell medium-9 small-order-2 medium-order-1 text-center medium-text-left">
© 2000 — <span id="current-year"></span> IHE International | TEL 1-630-481-1004 | 820 Jorie Boulevard,
Oak Brook, IL 60523
</div>
<div class="cell medium-3 small-order-1 medium-order-2 text-center medium-text-right ihe-footer-icons">
<a href="mailto:[email protected]"><i class="fi fi-mail"></i></a>
<a href="https://www.linkedin.com/company/iheintl"><i class="fi fi-social-linkedin"></i></a>
<a href="https://twitter.com/IHEIntl"><i class="fi fi-social-twitter" aria-hidden="true"></i></a>
<a href="https://www.youtube.com/user/IHEIntl"><i class="fi fi-social-youtube" aria-hidden="true"></i></a>
</div>
</div>
</div>
</footer>
<script src="../../../js/vendor/jquery.min.js"></script>
<script src="../../../js/vendor/motion-ui.min.js"></script>
<script src="../../../js/vendor/what-input.js"></script>
<script src="../../../js/vendor/foundation.min.js"></script>
<script src="../../../js/app.js"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-HLBNC861DJ');
</script>
</body>
</html>