FHIR Chat · Provenance in the Header

Stream: implementers

Topic: Provenance in the Header

Abbie Watson (Oct 11 2018 at 14:42):

Hi,
During the Baltimore Working Group infrasutrcture/tech dev meeting (Mon, 7pm), there was a discussion about serializing and putting Provenances in the HEADER of resources. Kinda wonky, but no criticism from me (or the others I've run this by). But.... we were wondering if there's any API spec for this yet? In hind sight, I'm not 100% clear whether that had been something proposed and started and going into R4, or if it was an implementation report by a single implementor, or if it was still at a purely ideation stage.
Thanks!

Lloyd McKenzie (Oct 11 2018 at 14:47):

What's the reason for doing that instead of a 'contained' Provenance?

Abbie Watson (Oct 11 2018 at 14:52):

Well, the Provenance acts as a shadow resource; so there's duplicate message overhead, and query search patterns on Provenances are a bit non-obvious.

But I didn't come up with the idea of putting them in the header. I'm just confirming what was discussed, and trying to... well, follow the provenance trail, actually.

Lloyd McKenzie (Oct 11 2018 at 14:55):

As contained, there should be no message overhead. It would mean it wouldn't be independently queriable, but that might not be essential. I'm not aware of any formal discussions to convey Provenance in a header.

Abbie Watson (Oct 11 2018 at 15:05):

Well, I first heard of the idea from our friends from Australia, so I'm just following along.

To clarify the use case, the Signature on the Provenance is useful for anybody wanting to sign resources; which then leads to auto-generated Provenances that just have a bunch of crypto signatures in them. That's where querying them becomes non-obvious. It's the Consent/Contract/Provenance use case. i.e. can we get a digital signature (i.e. provenance) riding along with a single resource query?

Abbie Watson (Oct 11 2018 at 15:10):

@Grahame Grieve - When you have a moment?

Grahame Grieve (Oct 11 2018 at 16:58):

Indeed it will be documented in R4 (there's a task for that). It's a pretty simple notion:

X-Provenance: {json}

where the json is a provenance resource with no target. The server fills in the target and commits it to the provenance resources. There's a length limitation, so you don't get to say very much. And the length limitation is variable - some server stacks limit individual headers to 2k or 4k. Some limit total to 8k

I haven't explored signatures on this yet.

What's the reason for doing that instead of a 'contained' Provenance?

You can do that if you want a contained provenance - which is bad idea. This is for if you want a normal provenance, but don't want a transaction every time.