This page is part of the FHIR Specification (v5.0.0: R5 - STU v6.0.0-ballot2: Release 6 Ballot (2nd Draft) (see Ballot Notes ). This is the The current published version in it's permanent home (it will always be available at this URL). is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

6.1.2 Digital Signatures

Security Work Group

Maturity Level : 1

Standards Status : Trial Use

Use case: "Digital Signature is needed to prove authenticity, integrity, and non-repudiation."

Approach: FHIR Resources are often parts of Medical Record or are communicated as part of formal Medical Documentation. As such there is a need to cryptographically bind a signature so that the receiving or consuming actor can verify authenticity, integrity, and non-repudiation. This functionality is provided through the signature element in Provenance Resource. Where the signature can be any local policy agreed to signature including Digital Signature methods and Electronic Signature.

Digital Signatures bind cryptographically the exact contents, so that any changes will make the Digital Signature invalid. When a Resource is created , or updated the server is expected to update relevant elements that it manages (id, lastupdated, etc.). These changes, although expected of normal RESTful create/update operations, will break any Digital Signature that has been calculated prior. One solution is to create the Digital Signature after the REST create operation completes, one must first confirm that the resulting created/updated Resource is as expected, then the Digital Signature is formed. Another solution is to use a canonicalization that excuses these dynamic elements.

A variation of this happens in Messaging, Documents, and other interaction models. For details, see Ramifications of storage/retrieval variations

This specification recommends the use of W3C Digital Signatures or JSON Digital Signatures for digital signatures. Resources can be signed using the Provenance resource to carry a detached digital signature . signature. The Signature datatype is available to support various signature types including non-repudiation purposes. Further details on creation and validation of Signatures are defined.

• The Signature SHOULD conform to XAdES-X-L for support of Long Term signatures . The XAdES-X-L specification adds the timestamp of the signing, inclusion of the signing certificate, and statement of revocation.
• The JSON Digital-Signature SHOULD conform to JAdES JAdES-B-LT for support of Long Term signatures.

In addition, documents Documents may be signed using an enveloped or enveloping signature. A specification for enveloped signature is and enveloping signatures on documents are profiled in the IHE DSG profile Document Digital Signature (DSG) Profile .

Neither of these definitions prohibits policies that accept SMART Health Cards defines a signature protocol for FHIR Bundles based on the use of other ways W3C Verifiable Credentials Data Model, and it has been internationally adopted for secure, granulart verification of using digital signatures or scanned wet signatures. health information such as COVID-19 immunizations and test results.

Note to Implementers: The use of signatures with RESTful interfaces is a poorly understood area, and we We would welcome reports of implementation experience. See discussion on use of Digital Signature in FHIR

Feedback is welcome here .