Stream: argonaut
Topic: Granularity & cardinality of Provenance.entity
Jay Lyle (Oct 17 2019 at 11:24):
We have some prior record data, but it's not just the prior resource: it's specific fields. Can we do something like this:
55.6114-.01 LAST RENEW (date): Provenance.period
55.6114-1 RENEWED BY (person): Provenance.agent.actor
55.6114-2 PREVIOUS PROVIDER (person): Provenance.entity.display (uri = order/12345/orderer)
55.6114-3 PREVIOUS STOP DATE/TIME (date): Provenance.entity.display (uri = order/12345/validityPeriod)
55.6114-4 PREVIOUS ORDERS FILE ENTRY (text): Provenance.entity.display (uri = order/12345/identifier)
@John Moehrke
John Moehrke (Oct 17 2019 at 12:24):
I don't understand . I certainly would not think that putting a URI into a .display element is a good solution. Can you elaborate on what it is that you are trying to record?
Jay Lyle (Oct 21 2019 at 13:09):
I didn't mean to suggest the uri go in the display.
There is a med order file, and this example is from the "last renew" subfile. Date and renewer fit Provenance just fine.
But it has three "this is the previous value" fields. Since Provenance.entity is 0..N, I can use it three times, but the respective "display" values have different locations in the record, hence the differentiating uri values. The spec suggests the entity 'type' doesn't have to be a resource; I'm suggesting it could be a resource element.
e.g.,
"entity": [
{
"role": "source",
"type": {
"system": "http://hl7.org/fhir/ValueSet/resource-element-type", <this does not exist, yet>
"code": "MedicationOrder.prescriber",
"display": "MedicationOrder.prescriber"
},
"reference": "MedicationOrder/91f55816-9e15-4b8b-87a9-2d7ade8670c8/prescriber",
"display": "Marcus Welby"
}, . . .
Alternatively, we could instantiate the prior version, include it inline, and direct the consuming application to look inside.
John Moehrke (Oct 21 2019 at 13:18):
ah, so we are adding that functionality to Provenance (to point to element within a resource). This is GF#23076. This is currently in FHIR-I hands.
This however is far more granular than original intent for Provenance, and far-far more ganular than "Basic Provenance" intends to support.
Jay Lyle (Oct 21 2019 at 16:02):
Thanks; switching to here
Last updated: Apr 12 2022 at 19:14 UTC
