Stream: implementers
Topic: Version in FHIR Resources
Grahame Grieve (May 12 2018 at 20:49):
We have 6-7 ballot comments about the need for including version in a resource. We have not done for this a number of reasons, but a small - well coordinated - portion of the community doesn't buy this.
Grahame Grieve (May 12 2018 at 20:52):
We will be discussing this subject this week in committee somewhere. If you're interested, or you're a party to the comments (I'll @ reference you later if you are), please let me know so we can schedule a discussion at as suitable time as we can for everyone.
Kevin Olbrich (May 12 2018 at 20:52):
@Grahame Grieve I'd like to understand this better as well, it's come up a few times in discussions around the versioned API. Please include me.
Grahame Grieve (May 12 2018 at 20:53):
in the meantime, @Chris Grenz points out that we don't need to - and shouldn't - add anything for this. You can already indicate what version a resource has if you want:
<Patient xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://hl7.org/fhir/DSTU2/StructureDefinition/Patient"/>
</meta>
</Patient>
Grahame Grieve (May 12 2018 at 20:54):
This is a statement that this patient resource conforms to the DSTU2 definition of a resource. That's exactly what's asked for, and exactly how it should be done, and has the advantage of not requiring any new element, and working just fine for DSTU 2-4, all versions.
Michel Rutten (May 12 2018 at 21:52):
I'd like to join the discussion if possible.
Christiaan Knaap (May 13 2018 at 15:12):
I'm interested in this as well
Alexander Henket (May 13 2018 at 15:19):
I'm interested. I'd first like to understand what we try to solve though. Could you point to the tracker items here, so we read into the comments before the discussion?
Grahame Grieve (May 13 2018 at 15:24):
current: GF#16165, GF#16127, GF#17002, GF#17001
Grahame Grieve (May 13 2018 at 15:25):
there is much history here. My brief summary:
Grahame Grieve (May 13 2018 at 15:25):
it's always been our intent that once stable, resources would not need versioning. And we have strong input from implementers that having versions in v2 messsages is strongly associated with barriers to integration.
Grahame Grieve (May 13 2018 at 15:26):
while FHIR was in trial use, we said we weren't going to solve this problem.
Grahame Grieve (May 13 2018 at 15:26):
but it's become clear that FHIR won't go to normative as a single spec.
Grahame Grieve (May 13 2018 at 15:27):
and we've ended up with the version in the metadata, rather than the data itself.
Grahame Grieve (May 13 2018 at 15:28):
e.g. the capability statement for an exchange (there is always one on rest) specifies the version, and there's no point to have a version in the instance.
Grahame Grieve (May 13 2018 at 15:28):
and- this is important - on the rest interface, the exchange is versioned, not the resource itself
Grahame Grieve (May 13 2018 at 15:29):
that's why the capability statement has the version
Grahame Grieve (May 13 2018 at 15:30):
outside the rest interface, though, life is different. And it's here - in storage related use cases etc, that people get really interested in the version in the instance. But we say: it's stupid to have the version of the thing you are reading inside the thing you are reading.
Grahame Grieve (May 13 2018 at 15:32):
so, continuing with that, we have defined that you can put the version alongside the resource - e.g. in your database, or in the mimetype for the content of the thing that carries the FHIR resource. e.g application/fhir+xml; fhir-version=3.0. Almost everywhere, you have a mime type (e.g. hl7 v2 message, SMTP header, MIME package of some kind, etc. So knowing the version ahead of time makes it much easier than looking inside the content
Grahame Grieve (May 13 2018 at 15:33):
but still there's a few places where having something along side is problematic. Naked resources stored in files on disks, for instance. And these things happen in a few places. And in other cases, people have built resources where they expect the version inside the thing they are reading, and they just don't want to change
Grahame Grieve (May 13 2018 at 15:34):
after all, HL7 has always done it this way... (whether we have or not)
Grahame Grieve (May 13 2018 at 15:36):
so there's several possible solutions:
- say that versioning in the mime type and the capability statement is fine
-- particularly given Chris's note above about Resource.meta.profile (and it's legacy support)
- add Resource.meta.version
- add a special version representation attribute/property for xml, json, and turtle that's at the root, not further in
Last updated: Apr 12 2022 at 19:14 UTC
