This page is part of the PACIO Advance Directive Information Implementation Guide (v1.0.0: STU 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Signatures

About Signatures

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

Data Consumers may require signatures from a Data Source to attest to the information being exchanged. For example, for a clinician to adequately review and follow a patient’s advance directive, the submitted information needs to be signed.¹² To comply with these signature requirements, this page documents how to create and verify FHIR Digital Signatures when using advance directives.

Signatures represent different levels of attestation:

• The signature represents a provider or patient 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 legal team for questions regarding legal liability associated with sharing and signing data.

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

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

The electronic signature is a JPG Image that represents this handwritten signature:

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

1. 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). ⁴

   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.

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

Sender/Signer Steps

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 “Modulus” and “Exponent” parameters of the entry.
2. Prepare JWS Payload
   1. 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 and populate the mandatory Signature datatype elements and actual signature content:
   • Signature.type - Set to the appropriate signature type, such as an Identity Witness 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

Receiver/Validation Steps

The following steps outline the process for verifying the Signature.

1. Retrieve and store the resource
2. Canonicalize the resource
3. Transform the canonicalized json to a base64-url format
4. Get the base64 encoded JWS from the signature.data element
5. Base64 decode the encoded JWS
6. Insert the base64 encoded data into the JWS payload element.
7. 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”
8. Verify Issuer, Validity Dates, Subject, and KeyUsage of the certificate,
9. Validate the JWS using the public key or the X.509 Certificate

---

Footnotes / References