Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1

Publication Build: This will be filled in by the publication tooling

## Signatures

Page standards status: Trial-use

### About Signatures

This specification does not require signatures but supports the transmission of signatures if business agreements require them.

Data Consumers such as Payers may require signatures from a Data Source to attest to the information being exchanged. For example, for a Centers for Medicare and Medicaid Services (CMS) worker to adequately review a Provider's claim, the submitted information needs to be signed.12 In direct query transactions without human intervention, Data Consumers may require signatures from Data Sources attesting that they supplied the information. To comply with these signature requirements, this page documents how to create and verify FHIR Digital Signatures when using CDex Transactions.

### The Signer

As illustrated in the table below, the signatory depends on the transaction. For synchronous or automated transactions, it is a system-level signature; for asynchronous transactions involving a human, it is a provider signature.

| Direct Query | Task Based Query | Attachments
--- | --- | --- | ---
System Level | X | X |
Human Provider |  | X | X

System-level and provider signatures represent different levels of attestation:

- The signature represents a provider signature attesting that the information is true and accurate to the best of their knowledge.*
- The signature representing the sending system is a system-level attestation by the sending organization that they supplied the information. It is a complete and accurate representation of the shareable information from that system, meeting the requested criteria. This signature does NOT attest that the information is accurate because the system can't make that determination.*

* Consult with your Payer and your legal team for questions regarding legal liability associated with sharing and signing data.

### What is Signed

The data returned in CDEX is not limited to FHIR resources but may also include C-CDA documents, PDFs, text files, and other formats. Depending on the data type and format returned, the signature may be in the actual payload or a FHIR Signature in the Bundle that envelopes the payload. The following table summarizes what artifacts are signed:

Data Type Returned | Location of Signature
--- | ---
Non-FHIR data formats attached to or referenced by DocumentReference (e.g., CCDA) | Referenced or attached data
FHIR Documents (e.g., CCDA on FHIR, Task-based request*, Unsolicited Attachment*) | Document Bundle
FHIR Search Bundle (e.g., a query response) | Search Bundle
FHIR QuestionnaireResponse (e.g., a query response) | QuestionnaireResponse
Combination of above (e.g., FHIR Search Bundle, FHIR Documents, or binary files referenced by DocumentReference) | Combination of Above

* A signed FHIR Document is sent for task-based requests and some attachments transactions when the artifact would otherwise, if unsigned, be individual FHIR resources.

The corresponding sections on signatures for Direct Query, Task Based Approach, Sending attachments, Requesting Attachments Using Attachment Codes, and Requesting Attachments Using Questionnaires document how to indicate the signature requirement and how to respond with signed transactions. The sections below define the requirements for using FHIR Signatures to sign a Bundle or QuestionnaireResponse with electronic or digital signatures. Refer to the appropriate specifications for guidance on signing other documents, such as CDA or CCDA on FHIR Documents.

### CDex Enveloped Signatures

Signatures in CDex are an element in the signed Bundle or QuestionnaireResponse resource. This type of signature is referred to as an enveloped signature. The FHIR Bundle is the envelope for Bundles, and the signature populates the `Bundle.signature` element. For QuestionnaireResponse, The envelope can be the resource, individual `QuestionnaireResponse.item` elements, or both, and the signature populates the QuestionnaireResponse's signature extension.* The enveloped signatures must avoid including the signature element in calculating the digital signature.

* When using a FHIR Questionnaire to request data, the [DTR SDC Questionnaire] Profile is used to profile the Questionnaire. Both CDex Task Attachment Request Profile and the [DTR SDC Questionnaire] profile have the overlapping capability to indicate that a signature is required. Signers must meet both the Task and Questionnaire signature expectations. The Task's signature input parameter represents the need for a verification signature for the QuestionnaireResponse. The DTR Standard Questionnaire profile supports many reasons for signatures, including verification signatures using the FHIR standard signatureRequired extension at the QuestionnaireResponse resource or `QuestionnareiResponse.item` level.

#### CDex Signature Profiles

This guide defines three profiles for using signatures:

1. CDex Signature Profile
2. CDex Signature Bundle Profile
3. CDex SDC QuestionnaireResponse Profile

##### CDex Signature Datatype Profile

This Signature DataType profile enforces the various elements of signature documented in the CDex guide. It adds the following mandatory (min=1) constraints:

- A `Signature.type` fixed to ASTM Standard, E1762-95(2013) code = “1.2.840.10065.1.12.1.5” (Verification Signature)
- A `Signature.who` for the organization or practitioner who signed the Bundle which is either:
  1. a reference to US-Core Practitioner, US-Core PractitionerRole, or US-Core Organization or
  2. an NPI or Tax ID and name of the organization or practitioner
- A `Signature.data` representing the base64 encoded Signature (JWS, image, etc)

In addition, the following mandatory (min=1) element is inherited from the base standard:

- `Signature.when` - a system timestamp when the signature was created

See the CDex Signature Profile formal definition for further details.

##### CDex Signature Bundle Profile

This Bundle profile enforces the various elements of signature documented in the CDex guide to represent an enveloped signature. It adds the following mandatory (min=1) constraint:

- A `Bundle.signature` element using the CDex Signature Profile

See the CDex Signature Bundle Profile formal definition for further details.

##### CDex SDC Questionnaire Response Profile

This profile is derived from the US Core QuestionnaireResponse Profile profile and enforces the various elements of signature documented in the CDex guide to represent an enveloped signature. It adds the following constraints:

- The signature extensions use the CDex Signature Profile

See the CDex SDC QuestionnaireResponse Profile formal definition for further details.

### Electronic Signatures

> The term "electronic signature" means an electronic sound, symbol, or process attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.3

The various forms of electronic signatures include:

- a typed-out name
- a graphical image that represents a handwritten signature
- a digitized handwritten signature
- digital signature using encryption technology

This guide specifies how to implement digital signatures in the following sections. Specific guidance for other electronic signatures is an implementation detail that is out of scope for this guide.

#### Electronic Signature Example

In this example, a `Bundle.signature` is added to a FHIR Document. The electronic signature is a JPG Image that represents this handwritten signature:

    0  {
    1    "resourceType" : "Bundle",
    2    "id" : "cdex-electronic-sig-example",
    3    "meta" : {
    4      "lastUpdated" : "2021-10-25T20:16:29-07:00"
    5    },
    6    "identifier" : {
    7      "system" : "urn:ietf:rfc:3986",
    8      "value" : "urn:uuid:c173535e-135e-48e3-ab64-38bacc68dba8"
    9    },
    10    "type" : "document",
    11    "timestamp" : "2021-10-25T20:16:29-07:00",
    12    "entry" : [{
    13      "fullUrl" : "urn:uuid:17a80a8d-4cf1-4deb-a1fd-2db1130e5f76",
    14      "resource" : {
    15        "resourceType" : "Composition",
    16        "id" : "17a80a8d-4cf1-4deb-a1fd-2db1130e5f76",
    17        "text" : {
    18          "status" : "generated",
    19          "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Composition_17a80a8d-4cf1-4deb-a1fd-2db1130e5f76\"> </a><p class=\"res-header-id\"><b>Generated Narrative: Composition 17a80a8d-4cf1-4deb-a1fd-2db1130e5f76</b></p><a name=\"17a80a8d-4cf1-4deb-a1fd-2db1130e5f76\"> </a><a name=\"hc17a80a8d-4cf1-4deb-a1fd-2db1130e5f76\"> </a><a name=\"17a80a8d-4cf1-4deb-a1fd-2db1130e5f76-en-US\"> </a><p><b>status</b>: Final</p><p><b>type</b>: <span title=\"Codes:{http://loinc.org 11503-0}\">Medical records</span></p><p><b>encounter</b>: <a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-5ce5c83a-000f-47d2-941c-039358cc9112\">Example Encounter</a></p><p><b>date</b>: 2021-10-25 20:16:29-0700</p><p><b>author</b>: <a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-0820c16d-91de-4dfa-a3a6-f140a516a9bc\">Example Practitioner</a></p><p><b>title</b>: Active Conditions</p><h3>Attesters</h3><table class=\"grid\"><tr><td style=\"display: none\">-</td><td><b>Mode</b></td><td><b>Time</b></td><td><b>Party</b></td></tr><tr><td style=\"display: none\">*</td><td>Legal</td><td>2021-10-25 20:16:29-0700</td><td><a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-0820c16d-91de-4dfa-a3a6-f140a516a9bc\">Example Practitioner</a></td></tr></table></div>"
    20        },
    21        "status" : "final",
    22        "type" : {
    23          "coding" : [{
    24            "system" : "http://loinc.org",
    25            "code" : "11503-0"
    26          }],
    27          "text" : "Medical records"
    28        },
    29        "subject" : {
    30          "reference" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    31          "display" : "Example Patient"
    32        },
    33        "encounter" : {
    34          "reference" : "urn:uuid:5ce5c83a-000f-47d2-941c-039358cc9112",
    35          "display" : "Example Encounter"
    36        },
    37        "date" : "2021-10-25T20:16:29-07:00",
    38        "author" : [{
    39          "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    40          "display" : "Example Practitioner"
    41        }],
    42        "title" : "Active Conditions",
    43        "attester" : [{
    44          "mode" : "legal",
    45          "time" : "2021-10-25T20:16:29-07:00",
    46          "party" : {
    47            "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    48            "display" : "Example Practitioner"
    49          }
    50        }],
    51        "section" : [{
    52          "title" : "Active Condition 1",
    53          "entry" : [{
    54            "reference" : "urn:uuid:014a68ec-d691-49e0-b980-91b0d924e570"
    55          }]
    56        }]
    57      }
    58    },
    59    {
    60      "fullUrl" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    61      "resource" : {
    62        "resourceType" : "Practitioner",
    63        "id" : "0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    64        "meta" : {
    65          "lastUpdated" : "2013-05-05T16:13:03Z"
    66        },
    67        "text" : {
    68          "status" : "generated",
    69          "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Practitioner_0820c16d-91de-4dfa-a3a6-f140a516a9bc\"> </a><p class=\"res-header-id\"><b>Generated Narrative: Practitioner 0820c16d-91de-4dfa-a3a6-f140a516a9bc</b></p><a name=\"0820c16d-91de-4dfa-a3a6-f140a516a9bc\"> </a><a name=\"hc0820c16d-91de-4dfa-a3a6-f140a516a9bc\"> </a><a name=\"0820c16d-91de-4dfa-a3a6-f140a516a9bc-en-US\"> </a><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Last updated: 2013-05-05 16:13:03+0000</p></div><p><b>identifier</b>: <a href=\"http://terminology.hl7.org/5.3.0/NamingSystem-npi.html\" title=\"National Provider Identifier\">United States National Provider Identifier</a>/9941339100</p><p><b>name</b>: John Hancock </p></div>"
    70        },
    71        "identifier" : [{
    72          "system" : "http://hl7.org/fhir/sid/us-npi",
    73          "value" : "9941339100"
    74        }],
    75        "name" : [{
    76          "family" : "Hancock",
    77          "given" : ["John"]
    78        }]
    79      }
    80    },
    81    {
    82      "fullUrl" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    83      "resource" : {
    84        "resourceType" : "Patient",
    85        "id" : "970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    86        "text" : {
    87          "status" : "generated",
    88          "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Patient_970af6c9-5bbd-4067-b6c1-d9b2c823aece\"> </a><p class=\"res-header-id\"><b>Generated Narrative: Patient 970af6c9-5bbd-4067-b6c1-d9b2c823aece</b></p><a name=\"970af6c9-5bbd-4067-b6c1-d9b2c823aece\"> </a><a name=\"hc970af6c9-5bbd-4067-b6c1-d9b2c823aece\"> </a><a name=\"970af6c9-5bbd-4067-b6c1-d9b2c823aece-en-US\"> </a><p style=\"border: 1px #661aff solid; background-color: #e6e6ff; padding: 10px;\">CDEX Example Patient Male, DoB Unknown ( Member Number)</p><hr/><table class=\"grid\"><tr><td style=\"background-color: #f3f5da\" title=\"Record is active\">Active:</td><td colspan=\"3\">true</td></tr></table></div>"
    89        },
    90        "identifier" : [{
    91          "type" : {
    92            "coding" : [{
    93              "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
    94              "code" : "MB"
    95            }]
    96          },
    97          "system" : "http://example.org/cdex/payer/member-ids",
    98          "value" : "Member123"
    99        }],
    100        "active" : true,
    101        "name" : [{
    102          "text" : "CDEX Example Patient",
    103          "family" : "Patient",
    104          "given" : ["CDEX Example"]
    105        }],
    106        "gender" : "male"
    107      }
    108    },
    109    {
    110      "fullUrl" : "urn:uuid:014a68ec-d691-49e0-b980-91b0d924e570",
    111      "resource" : {
    112        "resourceType" : "Condition",
    113        "id" : "014a68ec-d691-49e0-b980-91b0d924e570",
    114        "text" : {
    115          "status" : "generated",
    116          "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Condition_014a68ec-d691-49e0-b980-91b0d924e570\"> </a><p class=\"res-header-id\"><b>Generated Narrative: Condition 014a68ec-d691-49e0-b980-91b0d924e570</b></p><a name=\"014a68ec-d691-49e0-b980-91b0d924e570\"> </a><a name=\"hc014a68ec-d691-49e0-b980-91b0d924e570\"> </a><a name=\"014a68ec-d691-49e0-b980-91b0d924e570-en-US\"> </a><p><b>identifier</b>: <code>urn:oid:1.3.6.1.4.1.22812.4.111.0.4.1.2.1</code>/1</p><p><b>clinicalStatus</b>: <span title=\"Codes:{http://terminology.hl7.org/CodeSystem/condition-clinical active}\">Active</span></p><p><b>category</b>: <span title=\"Codes:{http://terminology.hl7.org/CodeSystem/condition-category problem-list-item}\">Problem List Item</span></p><p><b>code</b>: <span title=\"Codes:{http://snomed.info/sct 44054006}\">Type 2 Diabetes Mellitus</span></p><p><b>subject</b>: <a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-970af6c9-5bbd-4067-b6c1-d9b2c823aece\">Bundle: identifier = UUID:c173535e-135e-48e3-ab64-38bacc68dba8; type = document; timestamp = 2021-10-25 20:16:29-0700</a></p><p><b>onset</b>: 2006</p><p><b>asserter</b>: <a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-0820c16d-91de-4dfa-a3a6-f140a516a9bc\">Bundle: identifier = UUID:c173535e-135e-48e3-ab64-38bacc68dba8; type = document; timestamp = 2021-10-25 20:16:29-0700</a></p></div>"
    117        },
    118        "identifier" : [{
    119          "system" : "urn:oid:1.3.6.1.4.1.22812.4.111.0.4.1.2.1",
    120          "value" : "1"
    121        }],
    122        "clinicalStatus" : {
    123          "coding" : [{
    124            "system" : "http://terminology.hl7.org/CodeSystem/condition-clinical",
    125            "code" : "active"
    126          }]
    127        },
    128        "category" : [{
    129          "coding" : [{
    130            "system" : "http://terminology.hl7.org/CodeSystem/condition-category",
    131            "code" : "problem-list-item",
    132            "display" : "Problem List Item"
    133          }],
    134          "text" : "Problem List Item"
    135        }],
    136        "code" : {
    137          "coding" : [{
    138            "system" : "http://snomed.info/sct",
    139            "code" : "44054006",
    140            "display" : "Type 2 Diabetes Mellitus"
    141          }]
    142        },
    143        "subject" : {
    144          "reference" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece"
    145        },
    146        "onsetDateTime" : "2006",
    147        "asserter" : {
    148          "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc"
    149        }
    150      }
    151    },
    152    {
    153      "fullUrl" : "urn:uuid:5ce5c83a-000f-47d2-941c-039358cc9112",
    154      "resource" : {
    155        "resourceType" : "Encounter",
    156        "id" : "5ce5c83a-000f-47d2-941c-039358cc9112",
    157        "text" : {
    158          "status" : "generated",
    159          "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Encounter_5ce5c83a-000f-47d2-941c-039358cc9112\"> </a><p class=\"res-header-id\"><b>Generated Narrative: Encounter 5ce5c83a-000f-47d2-941c-039358cc9112</b></p><a name=\"5ce5c83a-000f-47d2-941c-039358cc9112\"> </a><a name=\"hc5ce5c83a-000f-47d2-941c-039358cc9112\"> </a><a name=\"5ce5c83a-000f-47d2-941c-039358cc9112-en-US\"> </a><p><b>status</b>: Finished</p><p><b>class</b>: <a href=\"http://terminology.hl7.org/6.1.0/CodeSystem-v3-ActCode.html#v3-ActCode-EMER\">ActCode EMER</a>: emergency</p><p><b>type</b>: <span title=\"Codes:{http://snomed.info/sct 261665006}\">Unknown (qualifier value)</span></p><p><b>subject</b>: <a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-970af6c9-5bbd-4067-b6c1-d9b2c823aece\">CDEX Example Patient</a></p><h3>Participants</h3><table class=\"grid\"><tr><td style=\"display: none\">-</td><td><b>Individual</b></td></tr><tr><td style=\"display: none\">*</td><td><a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-0820c16d-91de-4dfa-a3a6-f140a516a9bc\">John Hancock</a></td></tr></table><p><b>period</b>: 2021-10-25 20:10:29-0700 --&gt; 2021-10-25 20:16:29-0700</p><p><b>serviceProvider</b>: <a href=\"Bundle-cdex-document-digital-sig-example.html#urn-uuid-e37f004b-dc10-422b-b833-cdaa10a055a3\">CDEX Example Organization</a></p></div>"
    160        },
    161        "status" : "finished",
    162        "class" : {
    163          "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    164          "code" : "EMER"
    165        },
    166        "type" : [{
    167          "coding" : [{
    168            "system" : "http://snomed.info/sct",
    169            "code" : "261665006",
    170            "display" : "Unknown (qualifier value)"
    171          }],
    172          "text" : "Unknown (qualifier value)"
    173        }],
    174        "subject" : {
    175          "reference" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    176          "display" : "CDEX Example Patient"
    177        },
    178        "participant" : [{
    179          "individual" : {
    180            "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    181            "display" : "John Hancock"
    182          }
    183        }],
    184        "period" : {
    185          "start" : "2021-10-25T20:10:29-07:00",
    186          "end" : "2021-10-25T20:16:29-07:00"
    187        },
    188        "serviceProvider" : {
    189          "reference" : "urn:uuid:e37f004b-dc10-422b-b833-cdaa10a055a3",
    190          "display" : "CDEX Example Organization"
    191        }
    192      }
    193    },
    194    {
    195      "fullUrl" : "urn:uuid:e37f004b-dc10-422b-b833-cdaa10a055a3",
    196      "resource" : {
    197        "resourceType" : "Organization",
    198        "id" : "e37f004b-dc10-422b-b833-cdaa10a055a3",
    199        "text" : {
    200          "status" : "generated",
    201          "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Organization_e37f004b-dc10-422b-b833-cdaa10a055a3\"> </a><p class=\"res-header-id\"><b>Generated Narrative: Organization e37f004b-dc10-422b-b833-cdaa10a055a3</b></p><a name=\"e37f004b-dc10-422b-b833-cdaa10a055a3\"> </a><a name=\"hce37f004b-dc10-422b-b833-cdaa10a055a3\"> </a><a name=\"e37f004b-dc10-422b-b833-cdaa10a055a3-en-US\"> </a><p><b>identifier</b>: <a href=\"http://terminology.hl7.org/5.3.0/NamingSystem-npi.html\" title=\"National Provider Identifier\">United States National Provider Identifier</a>/1234567893</p><p><b>active</b>: true</p><p><b>name</b>: CDEX Example Organization</p><p><b>telecom</b>: ph: (+1) 555-555-5555, <a href=\"mailto:customer-service@example.org\">customer-service@example.org</a></p><p><b>address</b>: 1 CDEX Lane Boston MA 01002 USA </p></div>"
    202        },
    203        "identifier" : [{
    204          "system" : "http://hl7.org/fhir/sid/us-npi",
    205          "value" : "1234567893"
    206        }],
    207        "active" : true,
    208        "name" : "CDEX Example Organization",
    209        "telecom" : [{
    210          "system" : "phone",
    211          "value" : "(+1) 555-555-5555"
    212        },
    213        {
    214          "system" : "email",
    215          "value" : "customer-service@example.org"
    216        }],
    217        "address" : [{
    218          "line" : ["1 CDEX Lane"],
    219          "city" : "Boston",
    220          "state" : "MA",
    221          "postalCode" : "01002",
    222          "country" : "USA"
    223        }]
    224      }
    225    }],
    226    "signature" : {
    227      "type" : [{
    228        "system" : "urn:iso-astm:E1762-95:2013",
    229        "code" : "1.2.840.10065.1.12.1.5",
    230        "display" : "Verification Signature"
    231      }],
    232      "when" : "2021-10-05T22:42:19-07:00",
    233      "who" : {
    234        "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    235        "display" : "CDEX Example Practitioner"
    236      },
    237      "onBehalfOf" : {
    238        "reference" : "urn:uuid:e37f004b-dc10-422b-b833-cdaa10a055a3",
    239        "display" : "CDEX Example Organization"
    240      },
    241      "sigFormat" : "image/jpg",
    242      "data" : " "
    243    }
    244  }

### Digital Signatures

Digital Signatures are a type of Electronic signature that meet the following functional requirements:

1. authentication - They verify the identity of a person.
2. integrity - They ensure the signed document has not been altered.
3. non-repudiation - The signer can not dispute their authorship (For example, if there is subsequent legal activity related to the signed document).

Digital Signatures employ encryption technology and a digital certificate issued by a certification authority (CA). The encryption ensures the signee has attested to the integrity of the data. A certificate issued by a CA that the Data Consumer trusts, ensures that the Data Consumer can trust that the signature is authentic and non-repudiable.

#### Digital Signature Rules For CDEX FHIR Bundle and QuestionnaireResponse

1. SHALL use the CDex Signature Bundle Profile or CDex SDC QuestionnaireResponse Profile
2. SHALL use JSON Web Signature (JWS)(see RFC 7515)

   > 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). 4

   Implementers that support XML must be aware that JSON Web Signatures can only be created and validated in the original native JSON. Transforms to and from XML will invalidate signatures.

3. JSON Signature rules specified in the FHIR specification. (reproduced below for reader convenience):

   > When the signature is a JSON Digital Signature (contentType = application/jose), the following rules apply:

   > - The Signature.data is base64 encoded JWS-Signature RFC 7515: JSON Web Signature (JWS)
   > - The signature is a Detached Signature (where the content that is signed is removed from the JWS)
   > - When FHIR Resources are signed, the signature is across the Canonical JSON form of the resource(s)
   > - The Signature SHOULD use the hashing algorithm SHA256. The signature validation policy will apply to the signature and determine the acceptability
   > - The Signature SHALL include a "CommitmentTypeIndication" element for the purpose(s) of the signature. The Purpose can be the action being attested to or the role associated with the signature. The value shall come from ASTM E1762-95(2013). The `Signature.type` shall contain the same values as the CommitmentTypeIndication element.

   There is no "CommitmentTypeIndication" element in JWS, and a tracker (FHIR-36158) has been logged to update the FHIR specification. As documented in the CDex Profiles, `Signature.type` shall contain the value "1.2.840.10065.1.12.1.5" (Verification Signature).

4. Additional JWS rules for this guide:
   - SHALL support JWS compact serialization format for single signatures
     - Note that the complete JWS is in the form Header.Payload.Signature with a period `.` character between the base64_url encoded parts. This `Signature.data` value must be base64 encoded again as indicated above. Otherwise, it will fail validation since the base64Binary regex: (\s([0-9a-zA-Z+=]){4}\s)+ does not include the period `.` character.
   - SHOULD support JWS JSON Serialization format to represent multiple signatures with identical parameter values except `"x5c"`.
     - The signer may have more than one certificate (for example, the signer participates in more than one trust community)
   - SHALL use X.509 certificates to verify the identity of the entity signing the Bundle or QuestionnaireResponse
     - The KeyUsage SHOULD include 'DigitalSignature'
     - The Issuer SHOULD be a trusted CA for the Consumer
     - The Subject (or Subject Alternative Name (SAN)) SHOULD match the Data Source
     - The Validity Dates SHOULD be appropriate/long enough as determined by the business partners.
   - SHALL use the IETF JSON Canonicalization Scheme (JCS) (see RFC 8785) to generate the canonical form of the resource. JCS is a well-documented standardized canonicalization algorithm with multiple open-source implementations across several programming languages.
     - The `id`, `meta`, and `signature` elements on the root Bundle resource SHALL be removed before canonicalization. In other words, everything in a Bundle is signed except for these elements.
     - For signatures representing the entire QuestionnaireResponse, the `id`, `meta`, and the signature extension on the root QuestionnaireResponse resource SHALL be removed before canonicalization. In other words, everything in a QuestionnaireResponse is signed except for these elements.
     - For signatures representing an item in the QuestionnaireResponse, the `id` and the signature extension on the item resource SHALL be removed before canonicalization. In other words, everything in the `QuestionnaireResponse.item` is signed except for these elements.

##### Sender/Signer Steps

The following steps outline the process for creating the Signature.

1. Prepare JWS Header
   1. SHALL have `"alg": "RS256"` (preferred) or some other JSON Web Algorithms (JWA) (see RFC 7518)
   2. SHALL have `"kty": "RS"`
   3. SHALL have `"x5c"` (X.509 certificate chain) equal to an array of one or more base64-encoded (not base64url-encoded) DER representations of the public certificate or certificate chain (see RFC 7517). The public key is listed in the first certificate in the `"x5c"` specified by the entry's "Modulus" and "Exponent" parameters.
2. Prepare JWS Payload
   1. Prepare a valid FHIR Bundle or QuestionnaireResponse or QuestionnaireResponse.item
   2. Remove the `id` and `meta` elements.
   3. Canonicalize the Bundle or QuestionnaireResponse or QuestionnaireResponse.item
   4. base64_url encode the payload
3. Create the JWS signature using the supported algorithm.
4. Remove the payload element from the JWS.
5. base64 encode the JWS
6. Add the Signature element to the Bundle or the signature extension in the QuestionnaireResponse or QuestionnaireResponse.item and populate the mandatory Signature datatype elements and actual signature content:
   - `Signature.type` - Fixed to code = "1.2.840.10065.1.12.1.5" (Verification Signature)
   - `Signature.when` - System timestamp when signature created
   - `Signature.who` - Reference or identifier of the organization or practitioner who signed it
   - `Signature.data` - base64 encoded JWS
7. Send data to the consumer:
   1. The search set Bundle is returned directly as the payload for direct queries.
   2. For Task-based requests and Attachments, the document Bundle or QuestionnaireResponse is used

##### Receiver/Validation Steps

The following steps outline the process for verifying the Signature.

1. Retrieve and store the Bundle or QuestionnaireResponse :
   1. The search set Bundle is the response for a direct query.
   2. For Task-based requests, the completed `Task.output` is either:
      - a contained FHIR Document that must be extracted from the containing Task resource.
      - a reference to a FHIR Document that must be fetched from the referenced endpoint.
   3. A FHIR Document Bundle or QuestionnaireResponse is submitted as part of the operation payload for Attachments.
2. Remove the `id`, `meta` and `Bundle.signature` element from the Bundle resource or the signature extension(s) from the QuestionnaireResponse or QuestionnaireResponse.item.
3. Canonicalize the resource.
4. Transform the canonicalized JSON to a base64-url format.
5. Get the base64 encoded JWS from the `signature.data` element
6. Base64 decode the encoded JWS
7. Insert the base64 encoded Bundle, QuestionnaireResponse, or QuestionnaireResponse.item into the JWS payload element.
8. Obtain the public key from the first certificate in the JWS header `"x5c"` key
   - base64 decode the key value
   - Use the "Subject Public Key Info"
9. Verify Issuer, Validity Dates, Subject, and KeyUsage of the certificate,
10. Validate the JWS using the public key or the X.509 Certificate

##### Step-by-Step Examples

Although self-signed certificates are used for these examples, they are not recommended for production systems.

In these examples, a detached JWS signature is created using a signer's private key and self-signed certificate. Then, the `Bundle.signature` element is added to the Bundle with the base64 encoded JWS Signature as the `signature.data` property value. Finally, the signature is verified.

- Signed SearchSet Bundle Example : FHIR search-set bundle signatures occur when performing direct queries where signatures are required on the returned results. In this case, the digital signature represents a system-level attestation by the sending organization that they are the source of the information.

- Signed Document Bundle Example : FHIR Document bundle signatures occur when performing Task-based requests or Attachment transactions where signatures are required. The returned results are individual FHIR resources (in other words, not C-CDA, C-CDA on FHIR, or other binary formats referenced by DocumentReference). In this case, the digital signature represents a practitioner attesting that the information is true and accurate to the best of their knowledge.

1. MLN Fact Sheet: Complying with Medicare Signature Requirements MLN Fact Sheet https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/Downloads/Signature_Requirements_Fact_Sheet_ICN905364.pdf ↩

2. CMS signature requirements outlined in the Medicare Program Integrity Manual (CMS Pub.100-08), Chapter 3, Section 3.3.2.4. https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Downloads/pim83c03.pdf#page=44 ↩

3. "15 U.S. Code § 7006 - Definitions", LII / Legal Information Institute". Law.cornell.edu. Retrieved 2021-10-06. https://www.law.cornell.edu/uscode/text/15/7006#5 ↩

4. RFC 7515 Jones, M., et al., "JSON Web Signature (JWS)", RFC 7515, ISSN: 2070-1721, May 2015, https://tools.ietf.org/html/rfc7515 ↩