This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

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 signature. The Signature datatype is available to support various signature types including non-repudiation purposes.

• 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 Signature MAY conform to XAdES-T or any other profiling of XML-Signature.
• The JSON Digital-Signature SHOULD conform to JAdES-B-LT for support of Long Term signatures.
• The Signature MAY conform to JAdES-B-T or any other profiling of JOSE-Signature.

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

SMART Health Cards defines a signature protocol for FHIR Bundles based on the W3C Verifiable Credentials Data Model, and it has been internationally adopted for secure, granulart verification of health information such as COVID-19 immunizations and test results.

Note to Implementers: We would welcome reports of implementation experience. See discussion on use of Digital Signature in FHIR

Feedback is welcome here .