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

Da Vinci Clinical Data Exchange (CDex), published by HL7 International / Payer/Provider Information Exchange Work Group. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ecdx/ and changes regularly. See the Directory of published versions

## 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. 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 Signatures

In previous versions of this implementation guide, the term "enveloping" was used incorrectly to describe CDex Signatures

Signatures in CDex are represented as an element in the signed Bundle or QuestionnaireResponse resource. For FHIR Documents and FHIR Search Bundles, the signature populates the `Bundle.signature` element. The signature applies to the entire Bundle, ensuring that all contained resources are authenticated as a single unit. For QuestionnaireResponse, the signature populates the FHIR standard signatureRequired extension at the QuestionnaireResponse resource or `QuestionnareiResponse.item` level.*

* When using a FHIR Questionnaire to request data, the DTR Standard Questionnaire Profile is used to profile the Questionnaire. Both CDex Task Attachment Request Profile and the DTR Standard 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.

#### CDex Digital Signature Profiles

This guide defines three profiles for using signatures:

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

##### CDex Digital Signature Datatype Profile

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

##### CDex Signature Bundle Profile

This Bundle profile supports the signatures as documented in the CDex guide. It adds the following mandatory (min=1) constraint:

- A `Bundle.signature` element using:
  1. The CDex Digital Signature Profile for digital signatures
  2. The base Signature datatype for other electronic signatures (picture, etc)</span>

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. It adds the following constraints:

- The signature extensions use using:
  1. The CDex Digital Signature Profile for digital signatures
  2. The base Signature datatype for other electronic signatures (picture, etc)</span>

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 Examples

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    "identifier" : {
    4      "system" : "urn:ietf:rfc:3986",
    5      "value" : "urn:uuid:c173535e-135e-48e3-ab64-38bacc68dba8"
    6    },
    7    "type" : "document",
    8    "timestamp" : "2021-10-25T20:16:29-07:00",
    9    "entry" : [{
    10      "fullUrl" : "urn:uuid:17a80a8d-4cf1-4deb-a1fd-2db1130e5f76",
    11      "resource" : {
    12        "resourceType" : "Composition",
    13        "id" : "17a80a8d-4cf1-4deb-a1fd-2db1130e5f76",
    14        "text" : {
    15          "status" : "generated",
    16          "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><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>"
    17        },
    18        "status" : "final",
    19        "type" : {
    20          "coding" : [{
    21            "system" : "http://loinc.org",
    22            "code" : "11503-0"
    23          }],
    24          "text" : "Medical records"
    25        },
    26        "subject" : {
    27          "reference" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    28          "display" : "Example Patient"
    29        },
    30        "encounter" : {
    31          "reference" : "urn:uuid:5ce5c83a-000f-47d2-941c-039358cc9112",
    32          "display" : "Example Encounter"
    33        },
    34        "date" : "2021-10-25T20:16:29-07:00",
    35        "author" : [{
    36          "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    37          "display" : "Example Practitioner"
    38        }],
    39        "title" : "Active Conditions",
    40        "attester" : [{
    41          "mode" : "legal",
    42          "time" : "2021-10-25T20:16:29-07:00",
    43          "party" : {
    44            "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    45            "display" : "Example Practitioner"
    46          }
    47        }],
    48        "section" : [{
    49          "title" : "Active Condition 1",
    50          "entry" : [{
    51            "reference" : "urn:uuid:014a68ec-d691-49e0-b980-91b0d924e570"
    52          }]
    53        }]
    54      }
    55    },
    56    {
    57      "fullUrl" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    58      "resource" : {
    59        "resourceType" : "Practitioner",
    60        "id" : "0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    61        "text" : {
    62          "status" : "generated",
    63          "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><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>"
    64        },
    65        "identifier" : [{
    66          "system" : "http://hl7.org/fhir/sid/us-npi",
    67          "value" : "9941339100"
    68        }],
    69        "name" : [{
    70          "family" : "Hancock",
    71          "given" : ["John"]
    72        }]
    73      }
    74    },
    75    {
    76      "fullUrl" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    77      "resource" : {
    78        "resourceType" : "Patient",
    79        "id" : "970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    80        "text" : {
    81          "status" : "generated",
    82          "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><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>"
    83        },
    84        "identifier" : [{
    85          "type" : {
    86            "coding" : [{
    87              "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
    88              "code" : "MB"
    89            }]
    90          },
    91          "system" : "http://example.org/cdex/payer/member-ids",
    92          "value" : "Member123"
    93        }],
    94        "active" : true,
    95        "name" : [{
    96          "text" : "CDEX Example Patient",
    97          "family" : "Patient",
    98          "given" : ["CDEX Example"]
    99        }],
    100        "gender" : "male"
    101      }
    102    },
    103    {
    104      "fullUrl" : "urn:uuid:014a68ec-d691-49e0-b980-91b0d924e570",
    105      "resource" : {
    106        "resourceType" : "Condition",
    107        "id" : "014a68ec-d691-49e0-b980-91b0d924e570",
    108        "text" : {
    109          "status" : "generated",
    110          "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><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>"
    111        },
    112        "identifier" : [{
    113          "system" : "urn:oid:1.3.6.1.4.1.22812.4.111.0.4.1.2.1",
    114          "value" : "1"
    115        }],
    116        "clinicalStatus" : {
    117          "coding" : [{
    118            "system" : "http://terminology.hl7.org/CodeSystem/condition-clinical",
    119            "code" : "active"
    120          }]
    121        },
    122        "category" : [{
    123          "coding" : [{
    124            "system" : "http://terminology.hl7.org/CodeSystem/condition-category",
    125            "code" : "problem-list-item",
    126            "display" : "Problem List Item"
    127          }],
    128          "text" : "Problem List Item"
    129        }],
    130        "code" : {
    131          "coding" : [{
    132            "system" : "http://snomed.info/sct",
    133            "code" : "44054006",
    134            "display" : "Type 2 Diabetes Mellitus"
    135          }]
    136        },
    137        "subject" : {
    138          "reference" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece"
    139        },
    140        "onsetDateTime" : "2006",
    141        "asserter" : {
    142          "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc"
    143        }
    144      }
    145    },
    146    {
    147      "fullUrl" : "urn:uuid:5ce5c83a-000f-47d2-941c-039358cc9112",
    148      "resource" : {
    149        "resourceType" : "Encounter",
    150        "id" : "5ce5c83a-000f-47d2-941c-039358cc9112",
    151        "text" : {
    152          "status" : "generated",
    153          "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><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>"
    154        },
    155        "status" : "finished",
    156        "class" : {
    157          "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    158          "code" : "EMER"
    159        },
    160        "type" : [{
    161          "coding" : [{
    162            "system" : "http://snomed.info/sct",
    163            "code" : "261665006",
    164            "display" : "Unknown (qualifier value)"
    165          }],
    166          "text" : "Unknown (qualifier value)"
    167        }],
    168        "subject" : {
    169          "reference" : "urn:uuid:970af6c9-5bbd-4067-b6c1-d9b2c823aece",
    170          "display" : "CDEX Example Patient"
    171        },
    172        "participant" : [{
    173          "individual" : {
    174            "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    175            "display" : "John Hancock"
    176          }
    177        }],
    178        "period" : {
    179          "start" : "2021-10-25T20:10:29-07:00",
    180          "end" : "2021-10-25T20:16:29-07:00"
    181        },
    182        "serviceProvider" : {
    183          "reference" : "urn:uuid:e37f004b-dc10-422b-b833-cdaa10a055a3",
    184          "display" : "CDEX Example Organization"
    185        }
    186      }
    187    },
    188    {
    189      "fullUrl" : "urn:uuid:e37f004b-dc10-422b-b833-cdaa10a055a3",
    190      "resource" : {
    191        "resourceType" : "Organization",
    192        "id" : "e37f004b-dc10-422b-b833-cdaa10a055a3",
    193        "text" : {
    194          "status" : "generated",
    195          "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><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>"
    196        },
    197        "identifier" : [{
    198          "system" : "http://hl7.org/fhir/sid/us-npi",
    199          "value" : "1234567893"
    200        }],
    201        "active" : true,
    202        "name" : "CDEX Example Organization",
    203        "telecom" : [{
    204          "system" : "phone",
    205          "value" : "(+1) 555-555-5555"
    206        },
    207        {
    208          "system" : "email",
    209          "value" : "customer-service@example.org"
    210        }],
    211        "address" : [{
    212          "line" : ["1 CDEX Lane"],
    213          "city" : "Boston",
    214          "state" : "MA",
    215          "postalCode" : "01002",
    216          "country" : "USA"
    217        }]
    218      }
    219    }],
    220    "signature" : {
    221      "type" : [{
    222        "system" : "urn:iso-astm:E1762-95:2013",
    223        "code" : "1.2.840.10065.1.12.1.5",
    224        "display" : "Verification Signature"
    225      }],
    226      "when" : "2021-10-05T22:42:19-07:00",
    227      "who" : {
    228        "reference" : "urn:uuid:0820c16d-91de-4dfa-a3a6-f140a516a9bc",
    229        "display" : "CDEX Example Practitioner"
    230      },
    231      "onBehalfOf" : {
    232        "reference" : "urn:uuid:e37f004b-dc10-422b-b833-cdaa10a055a3",
    233        "display" : "CDEX Example Organization"
    234      },
    235      "sigFormat" : "image/jpg",
    236      "data" : " "
    237    }
    238  }

Several examples demonstrating the implementation and application of CDex Signatures are also provided on the FHIR artifacts page

### 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 and Guidance For CDEX Bundle and QuestionnaireResponse

1. SHALL use the CDex Digital Signature Profile with the CDex Signature Bundle Profile for digitally signed Bundles and with the CDex SDC QuestionnaireResponse Profile for for digitally signed QuestionnaireResponse. This Signature DataType profile enforces the various elements of digital signatures documented in this section.

2. Implementers SHALL follow the following FHIR R6 JSON Signature rules
   - The Signature.data is base64 encoded JWS-Signature [RFC 7515: JSON Web Signature (JWS)]
     - The JWS mime type `application/jose` SHALL be indicated in the `Signature.sigFormat` element.

     - > 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

   - The signature is a Detached Signature (where the content that is signed is removed from the JWS)
     - In other words, the `Bundle.signature` or the QuestionnaireResponse signatureRequired extension is removed before signing.

   - When FHIR Resources are signed, the signature is across the Canonical JSON form of the resource(s)

     - CDEX is pre-adopting the changes to FHIR R6 json canonicalization guidance and 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.

       - This canonicalization method is identified by the URI `application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json#document` and SHALL be indicated in the `Signature.targetFormat` element.

         Implementers that support both XML and JSON wire formats MAY support cross format signatures by:

         - Validating the JSON Web Signatures in the JSON format.
         - Canonicalizing the XHTML`text.div` narrative element following the FHIR R6 XML Canonicalization rules prior to the JSON canonicalization of the resource.
         - identifying This canonicalization method by the URI `application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json+xml#document` and SHALL indicate it in the `Signature.targetFormat` element.
     - `Bundle.id`, and `Bundle.meta` SHALL be removed before canonicalization. In other words, everything in a Bundle is signed except for these elements.
     - For signatures representing the entire QuestionnaireResponse, `QuestionnaireResponse.id`, and `QuestionnaireResponse.meta` elements 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 `QuestionnaireResponse.item.id` SHALL be removed before canonicalization. In other words, everything in the `QuestionnaireResponse.item` is signed except for these elements.
   - The signature SHALL include a `"srCms"` signer commitments" header element for the Purpose(s) of the Signature (see JAdES-B-T, page 17). 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 `"srCms"` header SHALL contain an `"id": "urn:oid:1.2.840.10065.1.12.1.5"` (Verification Signature)
     - The `Signature.type.code` elements SHALL contain the same values as the `"srCms"` header ids.
3. The signature Header:
   1. SHALL include an `"alg"` parameter for the JSON Web Algorithms (JWA) (see RFC 7518). `"alg": "RS256"` is preferred.
   2. SHALL include a `"kty"` parameter corresponding to the cryptographic algorithm family in `"alg"` ( e.g., `"kty": "RSA"` for `"alg": "RS256"` )
   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.
   4. SHALL include a `"sigT"` header parameter with a timestamp of the signature.
   5. SHALL include a `"srCms"` signer commitments as defined above.
4. SHOULD use the hashing algorithm SHA256. The signature validation policy will apply to the signature and determine the acceptability
5. 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.
6. 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)
7. The certificate SHALL include a Subject Alternative Name (SAN) which SHALL match the `Signature.who.identifier`
8. To verify the identity of the entity signing the Bundle or QuestionnaireResponse:
   - The certificate Issuer SHOULD be a trusted CA for the Consumer
   - The certificate KeyUsage SHOULD include 'DigitalSignature'
   - The certificate Validity Dates SHOULD be appropriate/long enough as determined by the business partners
   - One of the certificate Subject Alternative Name (SAN)) SHALL match `Signature.who.identifier` to verify the identity of the entity signing
   - The `"srCms"` Signer Commitments header ids SHALL match the `Signature.type.code` elements.
   - The `"Sigt"` header timestamp SHALL match `Signature.when`

##### Sender/Signer Steps

The following steps outline the process for creating the Signature.

1. Prepare JWS Header as defined above.
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 elements and as documented above and profiled in the CDex Digital Signature Profile
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 `.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

#### Digital Signature Examples

Several examples demonstrating the implementation and application of CDex Signatures are provided on the FHIR artifacts page

##### Step-by-Step Examples TODO: update to meet new rules

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 ↩