Stream: connectathon mgmt
Topic: C17 Versioned API
Grahame Grieve (Jan 09 2018 at 01:44):
welcome...
Peter Jordan (Jan 17 2018 at 20:08):
An additional (simple) use case scenario, to those on the Wiki, would be to make metadata requests based on versions contained in the Accept Header and test that responses contain the requisite Capability Statement. I've suggested adding this to Touchstone. Another scenario is to request r4-specific capabilities (e.g. CodesSystem$validate-code) when r3 is specified in the Accept Header - my (r3/r4) server will now return an operation outcome in this case.
Grahame Grieve (Jan 18 2018 at 10:18):
heads up on this - the only slot I have for a presentation is - I think - 2pm Eastern US time on Monday (I'll be at the airport on the way to US). I'll try and get a formal notification out tomorrow
Grahame Grieve (Jan 22 2018 at 20:07):
@Jenni Syed to answer your question about the accept header: my server will iterate the accept headers (split by ','), looking for application/fhir+[x]; fhir-version=Y, and use the first encountered version of Y, whether that's supportable for the particular exchange or not.
Grahame Grieve (Jan 27 2018 at 15:30):
ok I think, looking at the room, that we'll do track introduction here rather than in person - interested parties are just all over the place
Grahame Grieve (Jan 27 2018 at 15:31):
so at least my server fully supports all the scenarios somewhat
Grahame Grieve (Jan 27 2018 at 15:32):
who is interested in testing here.
Peter Jordan (Jan 27 2018 at 17:12):
+1 for returning r2,r3, r4 as versions. Interested in the use case for not returning a FHIR parameters resource if the accept header doesn't specify FHIR. Are there other precedents in the spec for returning 'raw' JSON or XML?
Grahame Grieve (Jan 27 2018 at 17:18):
no. there's no precedent
Grahame Grieve (May 13 2018 at 14:13):
@Kevin Olbrich http://test.fhir.org/r3/$versions is go now
Kevin Olbrich (May 13 2018 at 14:15):
FYI, @Brian Postlethwaite suggested an alternative. Populating the format section of the CapabilityStatement with a list of the possible mime types along with the supported version parameters. So it might contain application/json+fhir;fhirVersion=3.0, application/fhir+json;fhirVersion=1.0.
Grahame Grieve (May 13 2018 at 14:16):
an interesting idea
Grahame Grieve (May 13 2018 at 14:16):
but I really like $versions since the most common use of the conformance statement is to cehck the version.... $versions is just that
Kevin Olbrich (May 13 2018 at 14:17):
BTW is there a way to subset the CapabilityStatement to give back just the fhirVersion ?
Grahame Grieve (May 13 2018 at 14:19):
http://test.fhir.org/r3/metadata?_elements=fhirVersion&_format=json
Grahame Grieve (May 13 2018 at 14:19):
http://test.fhir.org/r3/metadata?_elements=fhirVersion,format&_format=json
Kevin Olbrich (May 13 2018 at 14:20):
Awesome! Now I can get my client to stop pulling in the entire thing.
Grahame Grieve (May 13 2018 at 14:21):
probably doesn't work on many servers
Christiaan Knaap (May 13 2018 at 14:29):
We do :-)
http://vonk.fire.ly/metadata?_elements=fhirVersion
Christiaan Knaap (May 13 2018 at 14:33):
And I'm afraid your response is a bit too sparse: "Servers SHOULD always return mandatory elements whether they are requested or not. Servers SHOULD mark the resources with the tag SUBSETTED to ensure that the incomplete resource is not actually used to overwrite a complete resource."
Grahame Grieve (May 13 2018 at 14:38):
hmm. I used to get that right
Grahame Grieve (May 13 2018 at 15:52):
@Christiaan Knaap this one is tricky.... _elements doesn't include the meta... so it's excluded...
Grahame Grieve (May 13 2018 at 15:53):
I guess we should document explicitly that meta is not subject to _elements
Christiaan Knaap (May 13 2018 at 19:29):
That would be clearer indeed. But since the tag 'SUBSETTED' must be added, you'll have to add meta anyway. And in this case a couple of other elements are mandatory and therefore included: status, date, kind, acceptUnknown, format.
Brian Postlethwaite (May 14 2018 at 07:38):
Ours too
http://sqlonfhir-stu3.azurewebsites.net/fhir/metadata?_elements=fhirVersion
Grahame Grieve (Jul 02 2018 at 22:19):
@Kevin Olbrich do we want to do this one again?
Kevin Olbrich (Jul 03 2018 at 14:07):
I don't think so, but @Andrew Marcus might disagree.
Grahame Grieve (Jul 03 2018 at 20:00):
maybe. but that's really about something else...
Kevin Olbrich (Jul 03 2018 at 20:45):
I agree, it's different. I don't feel like there's a lot more to iron out with the versioned api right now.
Last updated: Apr 12 2022 at 19:14 UTC
