Stream: questionnaire
Topic: Unversioned meta.proile for SDC?
Paul Lynch (Nov 07 2018 at 23:24):
I was relying on meta.profile to select between STU3 & R4 (per http://build.fhir.org/versioning.html#mp-version). However, the SDC profile has just: http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire, without a FHIR version number. Shouldn't there be a version number?
Brian Postlethwaite (Nov 08 2018 at 00:12):
you can still add in the core profile too.
Brian Postlethwaite (Nov 08 2018 at 00:13):
I'm looking forward to just doing R4 when I can migrate all our usage across, that's going to be my 1st Q next year.
Brian Postlethwaite (Nov 08 2018 at 00:14):
The profile itself doesn't need to say that, its a part of the bigger chain. and hope that R5 won't look significantly different :) but not holding my breath on that one
Lloyd McKenzie (Nov 08 2018 at 01:26):
To reference a specific version you can do this: "http://fhir/uv/sdc/StructureDefinition/sdc-questionnaire|2.0"
Brian Postlethwaite (Nov 08 2018 at 03:06):
That's not a version of FHIR, that's a version of the guide. @Paul Lynch is looking for the FHIR version aren't you?
Eric Haas (Nov 08 2018 at 04:59):
what about StructureDefinition.fhirVersion?
Brian Postlethwaite (Nov 08 2018 at 08:34):
I think Paul was meaning in the questionnaire instance.
Lloyd McKenzie (Nov 08 2018 at 12:27):
Identifying FHIR version in an instance is done using profile - as Paul already identified. Pretty sure he's looking for IG version...
Paul Lynch (Nov 08 2018 at 14:54):
@Lloyd McKenzie I thought I was looking for a FHIR version. Is there a FHIR version associated with SDC 2.0 (e.g. something like R4)? I would think there would need to be, since it is based on Questionnaire, which is a part of FHIR....
Lloyd McKenzie (Nov 08 2018 at 14:57):
The spec declares that it's based on 3.0.1
Lloyd McKenzie (Nov 08 2018 at 14:57):
(Asserted in the footer on each page)
Paul Lynch (Nov 08 2018 at 15:09):
@Eric Haas Brian is correct-- I am trying to determine the version from a instance. The case is where someone is uploading a file containing a Questionnaire resource, to be displayed in an SMART app using LForms to render it.
@Lloyd McKenzie Okay, so I can map from SDC versions to FHIR versions-- if the SDC version number is provided. The page at http://hl7.org/fhir/uv/sdc/2018Sep/sdc-questionnaire.html says the the official URL is "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire". Why wouldn't that include a version number? Also, is there someplace that says "http://fhir/uv/sdc/StructureDefinition/sdc-questionnaire|3.5.0" is the right format for specifying the version?
I saw a note at http://build.fhir.org/versioning.html#mp-version that the R4 version will be "4" when published. Does that mean that these 3.5.0 URLs will change to 4.0 when it is published?
Lloyd McKenzie (Nov 08 2018 at 15:12):
Determining the instance can be done using profile - but there's no requirement that instances will do so. If your SMART app is expecting to handle multiple versions of FHIR, you should allow it to be launched with a parameter that identifies version from context as that will be the other common convention. Other than that, you could look for certain characteristic differences in the different versions of the resources passed in
Paul Lynch (Nov 08 2018 at 15:32):
Because the demo app is in the SMART App Gallery, which does not yet have an option for R4, and yet the purpose of the app is to demo new the SDC (which requires R4), communication with the App Gallery FHIR server is over R3, but I am trying to allow the upload of R4 forms (which can be displayed as R4, but not saved as R4).
Brian Postlethwaite (Nov 08 2018 at 21:43):
Hmm, I'm feeling your pain there.
From the stuff we've been doing, we have seperate versions of our engines for each fhir version.
With R4 going normative, we're hoping to change that.
For other stuff I just use the parsers to work it out.
Check what I do in Fhirpathtester. If the types or extensions are only from a specific version, then all good.
We haven't changed the meaning of any properties or extensions. However between 2 and 3 the fhirpath syntax igbtly changed
Grahame Grieve (Nov 09 2018 at 00:26):
you should look at http://build.fhir.org/versioning.html
Paul Lynch (May 26 2021 at 21:23):
From the point of view of a client rendering a Questionnaire, putting the version of the IG's Questionnaire profile in meta.profile might be less useful that directly specifying the version of FHIR that is supported, like http://hl7.org/fhir/4.0.1/StructureDefinition/Questionnaire. Otherwise, the renderer has to know (or figure out) what version of FHIR any IG's Questionnaire profile is based on. Can both the IG profile version and the FHIR Questionnaire version be specified in meta.profile?
Lloyd McKenzie (May 26 2021 at 22:55):
An instance can expose the FHIR version in the profile - see here: https://build.fhir.org/versioning.html#mp-version
However most of the time, it'll be known from HTTP content negotiation or mime type.
Paul Lynch (May 27 2021 at 14:30):
We have web apps where people can upload a file containing a Questionnaire, so we have to detect the version from the resource itself.
Lloyd McKenzie (May 27 2021 at 15:24):
The upload doesn't have a header that passes the mime type?
Paul Lynch (May 27 2021 at 18:26):
No. It is a standard "input type=file" button in the web page, which opens a file chooser for the user to pick a file from their computer for uploading.
Lloyd McKenzie (May 27 2021 at 19:28):
Even that normally has a mime type passed in. If you upload an Excel, Javascript normally can tell that as something distinct from a PNG?
Paul Lynch (May 27 2021 at 19:31):
Okay, possibly it might say "application/json", but I don't see how that would help in detecting which version of FHIR it is.
Lloyd McKenzie (May 27 2021 at 20:41):
It could say application/fhir+json;fhirVersion=4.0. Is that something your RESTful client has any ability to know/specify? If systems are just going to drag and drop or do a file select on an arbitrary Questionnaire version, you've got 2 options - have an additional webform control that allows them to pick the version from a drop-down, or simply validate the input against the versions you recognize until you find one it doesn't fail on. Instances, in general, won't declare their versions in the instance.
Lloyd McKenzie (May 27 2021 at 20:41):
(And making users edit the instances to assert a version profile won't make your tool terribly user-friendly.)
Paul Lynch (May 27 2021 at 20:46):
The "it" specifying the mime type is not the web app doing the rendering, but the web browser or OS. Google Chrome or Windows 10 isn't likely to recognize certain JSON files as being FHIR R4 anytime soon.
We do try to guess the FHIR version if it isn't specified in meta.profile, but we check meta.profile first in case someone has specified it there.
Lloyd McKenzie (May 27 2021 at 20:47):
Sounds like the appropriate thing to do.
Paul Lynch (May 27 2021 at 20:47):
Why wouldn't it be good for FHIR to require that every instance of a resource assert which FHIR version it is? There must be some reason, I suppose.
Lloyd McKenzie (May 27 2021 at 21:45):
Because we want receivers to be tolerant of version differences
Lloyd McKenzie (May 27 2021 at 21:46):
If you receive an Observation that doesn't declare its version, you can quite likely successfully process it if you're set up to consume R4, STU3 or DSTU2 instances. We know from experience with v2 that receiving the equivalent in v2 space (which does declare version) can mean a charge of $100k+ to "add support" for a new version.
Paul Lynch (May 27 2021 at 21:50):
I can likely process an undeclared version, but I am much more likely to be able to process a version that is known that I do support. If it is an unknown version, one can always fall back to the undeclared case. But, maybe you are saying that software tends not to be written that way if the authors know a version is required.
Lloyd McKenzie (May 27 2021 at 22:13):
Right. There's also an incentive (and pattern) of introducing a 'tax' around support for new versions that isn't necessarily justified.
Last updated: Apr 12 2022 at 19:14 UTC
