Stream: implementers
Topic: Direct Sending / versions
Grahame Grieve (Jun 23 2018 at 08:16):
hi @Luis Maas @Julie Maas I've just run into an issue with my direct implementation. For background, see this page: http://build.fhir.org/versioning.html. Sending resources by direct is one of those cases where there's no applicable capability statement on which to determine the version. We can do one of 2 things:
- require that destinations have different direct destinations for different versions of FHIR
- require that direct messages include the fhirVersion parameter on the mime type
Grahame Grieve (Jun 23 2018 at 08:17):
I think the second makes way more sense than the first, so propose that we make the fhirVersion parameter mandatory for direct. Does that make sense to you?
Luis Maas (Jun 25 2018 at 00:28):
yes both would work. you could also express the version in the resource metadata as per the link you provided. the mime type version parameter might be preferable so version doesn't need be an column in directories. If the endpoint supports Direct context, one could also request the capability statement via Direct and use the same versioning semantics as in the above link.
Grahame Grieve (Jun 25 2018 at 10:25):
good. version in the mime type it is
Paul Knapp (Jul 11 2018 at 12:05):
@Luis Maas @Julie Maas @Grahame Grieve the version in the mime type is fine but I would also expect the version to be in the resource.meta so that it isn't lost one the transport wrappers are removed.
Grahame Grieve (Jul 11 2018 at 12:17):
you can expect that, but not everyone will
Lloyd McKenzie (Jul 11 2018 at 14:02):
You're free to add it in on receipt if you need it too.
Lloyd McKenzie (Jul 11 2018 at 14:03):
(And doing it yourself is better for overall interoperability than rejecting data from other systems until they all customize to save you writing a few lines of code...)
Last updated: Apr 12 2022 at 19:14 UTC
