Stream: implementers
Topic: Provenance entity reference
Michael Lawley (Feb 27 2019 at 01:22):
Our terminology server creates SNOMED, LOINC, and other CodeSystem resources from 3rd party artefacts (eg SNOMED's RF2 source files). These come to us with a client-provided hash-based signature which we want to surface so that there's traceability from the CodeSystem in the terminology server to the source via this client-provided hash.
I had thought of this as Provenance following this: http://hl7.org/fhir/provenance.html#6.3.4.5 but am struggling with where the hash should go.
Lloyd McKenzie (Feb 27 2019 at 01:46):
Probably an extension
Michael Lawley (Feb 27 2019 at 03:46):
And would I use Device to represent the software itself (as the transforming agent)?
Lloyd McKenzie (Feb 27 2019 at 04:02):
y
John Moehrke (Feb 27 2019 at 15:03):
the hash could go into Provenance.signature. There is nothing against any form of signature being used. You would put the hash value into Provenance.signature.data. What you do need to do is find a MIME-Type for that kind of 'file'.. as in a file that is nothing but a SHA-256 hash value. I don't know of a mime-type for this, but that doesn't mean there isn't one... if there isn't one, then you create your own mime-type following the mime-type extentibilty method.
John Moehrke (Feb 27 2019 at 15:07):
there is no requirement that Signature contain a cryptographic signature. Local policy, or Implementation Guides, would restrict. There are plenty of places just capturing ink-on-paper in a JPEG and putting that image there.
Jens Villadsen (Feb 27 2019 at 15:11):
SHA-256 sounds like an MD5 file which has mimetype text/plain
John Moehrke (Feb 27 2019 at 15:15):
true. but it wouldn't hurt to be a bit more specific. text/plain+sha256
Michael Lawley (Mar 18 2019 at 09:35):
+sha256 would be nice, but using unregistered suffixes is explicitly discouraged
Last updated: Apr 12 2022 at 19:14 UTC
