Stream: argonaut
Topic: US Core Provenance Profile
SSM (Nov 30 2020 at 18:13):
Hi Team,
I need a clarification whether a separate API needs to be built as part of USCore provenance profile for the provenance resource or provenance can support the profiles through search options provided in USCore Provenance. There is a statement given in the USCore server capability statement for Provenance as mentioned below -
Fetch and Search Criteria for Provenance -
A Server SHALL be capable of returning a Provenance resource using:
GET [base]/Provenance/[id]
So does this mean that in addition to support the provenance for other resources such as Observation or Allergy Intolerance or care plan etc.in their API search option, Provenance itself is mandatory to have its own API with Provenance logical ID search? Please clarify.
Michele Mottini (Nov 30 2020 at 18:23):
Not sure what you mean. To 'to support the provenance for other resources such as Observation or Allergy' you need to implement the Provenance resource, and yes, that means that at the very least the server should support GETting Provenance doing a GET [base]/Provenance/[id]
John Moehrke (Nov 30 2020 at 18:44):
One would tend to get the Provenance thru the reverse include search parameter (_revinclude) on the other Resources. Thus there is not a need to mandate any specific Provenance search API. So what you see there is just retrieve, not a search. This does mean that for all the other US-Core resources they MUST support the _revinclude search parameter. The down side is that if you forgot to _revinclude, and you have an other Resource. You can't do a query against Provenance for target equal to that other Resource id. This is indeed not mandated.
Yunwei Wang (Nov 30 2020 at 19:23):
US Core IG says that system SHALL support search with _revInclude=Provenance:target
http://hl7.org/fhir/us/core/StructureDefinition-us-core-provenance.html#mandatory-search-parameters
Yunwei Wang (Nov 30 2020 at 19:25):
@SSM Yes. Server SHALL support read Provenance using its id.
SSM (Nov 30 2020 at 20:06):
Yunwei Wang said:
@SSM Yes. Server SHALL support read Provenance using its id.
@Yunwei Wang - Just to reconfirm are you recommending that Provenance will have a separate API apart from _revinclude search.
Yunwei Wang (Nov 30 2020 at 20:38):
I don't quite understand what "separate API" mean. Just as IG states, server SHALL support GET [base]/Provenance/[id]
John Moehrke (Nov 30 2020 at 20:45):
I was just distinguishing a GET id from a GET with search parameters.
SSM (Nov 30 2020 at 21:16):
Separate API means i am referring to Provenance having its own API endpoint.
John Moehrke (Nov 30 2020 at 21:48):
do you have the answer to the question? Yes you must support Provenance/id; you are not required to support Provenance search. But you are not forbidden from supporting Provenance search. Search by target would be helpful; but was not seen as universally supported by all possible servers that would be compelled to implement us-core
Cooper Thompson (Jul 05 2021 at 15:26):
Picking this back up - but in what case do folks think a Provenance.read would make sense?
Douglas DeShazo (Jul 06 2021 at 13:11):
Is anyone seeing use cases with Provenance contained as opposed to being returned in a searchset bundle along with it's target resource? Or is this better for the implementers stream?
David Pyke (Jul 06 2021 at 15:27):
@John Moehrke
John Moehrke (Jul 06 2021 at 15:30):
What is the reasoning behind wanting it contained? the use of contained should be only used when there is not enough detail to standalone. A big problem I see with containment of Provenance is how revisions are handled.
Douglas DeShazo (Jul 06 2021 at 18:37):
Thanks @John Moehrke No reason was given. I got involved with an implementation after the fact and was questioning the exact same thing. My take is how you see it so I'm comfortable with my position. Thanks again. I'll try to get a reason for containing it and post here.
Last updated: Apr 12 2022 at 19:14 UTC
