Stream: implementers
Topic: Digital Signing with Provenance
Dave Barnet (May 06 2020 at 12:53):
I'm looking to a generic digital signing capability, and am looking to use the Provenance resource. The generic capability will have to cover FHIR based digital signing (signing a MedicationRequest as prescription signing for example), as well as more generic use cases that may not be FHIR based (contracts, non-FHIR documents etc.). The general premise is that there will be a signing service (cloud based - but that's not really relevant) used across the organisation. Does anyone have any experience of implementing something like this? If so, are there any pit-falls to watch out for, any common extensions that people have used? Any guidance would be useful. Is using the Provenance resource any better than a JSON object when you're not in a wholly FHIR environment?
John Moehrke (May 06 2020 at 15:39):
Provenance does include a place to preserve a digital signature. This supports in some way all the use-cases you have outlined, but there is certainly some additional specification you would need to include. The main goal of Provenance.signature is to support a digital signature that covers the resources pointed to by Provenance.target. So it is not intended to cover other use-cases without mind-bending creativity. This said, the actual signature would it-self explain what it it-self covers. Meaning one would find in the XML-Signature the manifest of what is signed and the seralization and canonicalization used. (JSON is not as declarative and requires more art).
John Moehrke (May 06 2020 at 15:44):
I am sure you have seen the warnings in the FHIR Core around signatures... so I welcome your lessons learned
Last updated: Apr 12 2022 at 19:14 UTC
