This page is part of the Da Vinci Clinical Documentation Exchange (v2.0.0: STU2) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions
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. It is a system-level signature for synchronous or automated transactions; 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 types of data. 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. For Bundles, the FHIR Bundle is the envelope, 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 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 SDC Questionnaire profile supports many types of 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:
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:
a reference to US-Core Practitioner, PractitionerRole or Organization or
an NPI or Tax ID and name of the organization or practitioner
A Signature.data representing base64 encoded JWS-Signature
In addition, the following mandatory (min=1) element is inherited from the base standard:
Signature.when - system timestamp when the signature was created
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
This extension is derived from the SDC Questionnaire Response 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
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:
Digital Signatures are a type of Electronic signature that meet the following functional requirements:
authentication - They verify the identity of a person.
integrity - They ensure the signed document has not been altered.
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
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.
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 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).
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 period (‘.’) characters 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 all parameter values identical 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
Prepare JWS Header
SHALL have "alg": "RS256" (preferred) or some other JSON Web Algorithms (JWA) (see RFC 7518)
SHALL have "kty": "RS"
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 “Modulus” and “Exponent” parameters of the entry.
Prepare JWS Payload
Prepare a valid FHIR Bundle or QuestionnaireResponse or QuestionnaireResponse.item
Canonicalize the Bundle or QuestionnaireResponse or QuestionnaireResponse.item
base64_url encode the payload
Create the JWS signature using the supported algorithm.
Remove the payload element from the JWS.
base64 encode the JWS
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.when - System timestamp when signature created
Signature.who - Reference or identifier of the organization or practitioner who signed it
Signature.data - base64 encoded JWS
Send data to the consumer:
The search set Bundle is returned directly as the payload for direct queries.
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.
Retrieve and store the Bundle or QuestionnaireResponse :
The search set Bundle is the response for a direct query.
For Task-based requests, the completed Task.output is either:
a contained FHIR document and must first be ‘decontained’
a reference to a FHIR document, and must be fetched from the referenced endpoint.
A FHIR Document Bundle or QuestionnaireResponse is submitted in the operation payload for Attachments.
Remove the Bundle.signature element from the Bundle resource or the signature extension(s) from the QuestionnaireResponse or QuestionnaireResponse.item.
Canonicalize the resource.
Transform the canonicalized json to a base64-url format.
Get the base64 encoded JWS from the signature.data element
Base64 decode the encoded JWS
Insert the base64 encoded Bundle, QuestionnaireResponse, or QuestionnaireResponse.item into the JWS payload element.
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”
Verify Issuer, Validity Dates, Subject, and KeyUsage of the certificate,
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.
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.
FHIR document bundle signatures occur when performing Task-based requests or Attachment transactions where signatures are required, and 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.
|
Propose a change