Stream: argonaut
Topic: Versions
Jay Lyle (Feb 11 2019 at 22:02):
Argonaut data query is built on R2, but several of the Reference specs link to R3 resources. Is this a mistake, or does Argonaut intentionally mix versions? Can a server assert conformance to R2 for some resources and R3 for others?
Michele Mottini (Feb 11 2019 at 22:58):
No, server cannot mix versions. The Argonaut implementation guide for DSTU2 is now the US Core implementation guide for STU3 (and R4)
Jay Lyle (Feb 12 2019 at 15:28):
Thanks Michele, your first sentence makes sense and is very helpful.
I'm having trouble digesting the second. Looking at what the specification links point to, I see this:
Argonaut Data Query is DSTU2
Argonaut Clinical Note is USCore/STU3
Argonaut Appointment is USCore/STU3
Argonaut Provider Directory claims STU3 but links are unversioned & resolve to 4
Argonaut Questionnaire is STU3
This suggests an "Argonaut" implementation is either Data Query/2 or everything else/3. True?
Eric Haas (Feb 12 2019 at 15:52):
In the common vernacular when people say "Argonaut" they mean Argonaut Data Query DSTU2. The Argonaut Project has produced several other implementation guides but they are typically referred to by their full name.
Eric Haas (Feb 12 2019 at 15:53):
So for example I'm working on Argo Questionnaire and it would be referred to Argonaut Questionnaire
Eric Haas (Feb 12 2019 at 15:53):
and it is Argo Scheduling Guide not Appointment
Grahame Grieve (Feb 13 2019 at 11:38):
it's a deliberate choice that the versions differ, and so they couldn't be on the same end-point
Grahame Grieve (Feb 13 2019 at 11:38):
the provider directory is a special case: it was started based on R3 but has migrated to R4. It should not claim to be R3 based anymore.
Brett Marquard (Feb 15 2019 at 15:53):
Interesting. Argonaut PD completed long before FHIR R4 so any links to are unintentional. @Jay Lyle do you mind providing a few?
Jay Lyle (Feb 15 2019 at 15:56):
I think they're all like this, but e.g. on
http://www.fhir.org/guides/argonaut/pd/StructureDefinition-argo-practitioner.html
The Practitioner link has target http://hl7.org/fhir/practitioner.html
Brett Marquard (Feb 15 2019 at 16:02):
Thanks Jay. @Grahame Grieve looks like I didn't properly link to FHIR core version (STU3 at the time) properly in the IG, is there a way to do an errata release to fix
Jay Lyle (Feb 15 2019 at 21:27):
What about extensions? E.g., http://hl7.org/fhir/StructureDefinition/condition-related is linked to from the R4 publication, but it doesn't seem to assert a version. Can it be used by servers conforming to R2 & Argonaut DQ?
Eric Haas (Feb 15 2019 at 22:25):
(deleted)
Eric Haas (Feb 15 2019 at 22:27):
note that the ig publishing now prevents us authors from doing stupid things like this...
Eric Haas (Feb 15 2019 at 22:42):
the canonical for that extension resolves to R4 there is no STU3 or DSTU2 version but if there were you could tack on the version. Are you asking if you can back port R4 extensions into earlier versions rather than create your own? @Grahame Grieve or @Lloyd McKenzie ? I think that is in the works???
Lloyd McKenzie (Feb 15 2019 at 22:46):
I think the intention is for us to be able to use extensions defined in later versions in earlier versions, but I don't know where we're at in the process of enabling that...
Grahame Grieve (Feb 17 2019 at 13:16):
I think this is my fault that it's a version independent link but shouldn't be.
Martijn Harthoorn (Apr 19 2019 at 09:30):
Grahame, the US-core profiles on Simplifier that you uploaded for HL7 International, state that they are of FHIR version 3.1.0.
We have a user that is confused by that. Is this an experimental version - or is it the same as 3.0.1 ?
Martijn Harthoorn (Apr 19 2019 at 09:30):
https://simplifier.net/US-Core/allergyintolerance/~xml
Brett Marquard (Apr 19 2019 at 13:27):
A draft version on FHIR R4 is here: https://build.fhir.org/ig/HL7/US-Core-R4/
Josh Mandel (Apr 19 2019 at 13:43):
Nice! Quick question on the birth sex extension: is it kosher to bind a code (rather than a coding) to a valueset with content from multiple systems? (This seems fragile to me.)
Josh Mandel (Apr 19 2019 at 13:46):
And for ethnicity:
One or more Ombcategory Extensions in Extension.extension
which must have a fixed Extension.extension.url = ombCategory
How is "ombCategory" a valid extension URI? Or am I misinterpreting this somehow?
Brett Marquard (Apr 19 2019 at 13:46):
ugh. I agree. @Eric Haas Any memory why we did that?
Josh Mandel (Apr 19 2019 at 13:49):
(hmm, for ethnicity I guess I'm looking at a nested complex extension field --- okay, just got tripped up by the documentation format.)
Josh Mandel (Apr 19 2019 at 13:50):
But the requirement "An uri in Extension.url" on https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-ethnicity.html doesn't make sens
Josh Mandel (Apr 19 2019 at 13:51):
Similarly on https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-direct.html -- I'm guessing that the actual extension URL is supposed to be present, but is being omitted by the publication tool?
Josh Mandel (Apr 19 2019 at 13:52):
(this is an issue with the "text summary" view, which is the default.)
Lloyd McKenzie (Apr 19 2019 at 13:57):
@Josh Mandel Yes, binding to poly-system value sets is allowed, but they should always be extensional (enumerated) value sets so there's no risk of there being any confusion about which code goes with which system.
Josh Mandel (Apr 19 2019 at 13:59):
Do we have guidance about when you'd want to make this kind of binding rather than using a Coding? Presumably over time the value set could expand, and using just a Code might become a liability.
Lloyd McKenzie (Apr 19 2019 at 14:06):
If you're using 'code', the expectation is that the codes themselves must be meaningful. The only time I'm aware of us doing this was to combine null flavors (from the v3 code system) with other codes from a different v3 code system. With a manually curated enumerated value set, there's extremely little risk of collisions.
Eric Haas (Apr 19 2019 at 16:04):
The birth sex extension is non negotiable. I worked Rob McClure and VSAC on that one. We use mixed code systems all the time. This is a decision to not create and maintain our own code systems.
Lloyd McKenzie (Apr 19 2019 at 16:05):
(Provided we can find external code systems that meet our needs.)
Eric Haas (Apr 19 2019 at 16:13):
The summaries are freshly minted from generation tool I created vs hand editing them all. I agree the extensions are clunky and need to be edited by hand. I am trying make it less onerous to maintain and more consistent with fewer errors and typos. I’m using Jinja2 with the python fhirclient library and is in a Jupiter notebook for sharing on my github site if anyone wants to contribute. (I chose markdown which is harder to template but easier to hand edit btw. )
Josh Mandel (Apr 19 2019 at 16:13):
(certainly I wasn't suggesting creating a new code system -- just using Codings from existing ones )
Josh Mandel (Apr 19 2019 at 16:34):
@Eric Haas I'm not really familiar with the tools for editing this stuff; could you share a GitHub link or two that illustrate what you mean?
Eric Haas (Apr 19 2019 at 23:15):
https://github.com/Healthedata1/MyNotebooks/blob/master/Summary-maker/summary_maker.ipynb
Jay Lyle (Oct 31 2019 at 14:38):
I think this is my fault that it's a version independent link but shouldn't be.
Does this mean that, "the intention" notwithstanding, we need to define a DSTU2 extension?
Last updated: Apr 12 2022 at 19:14 UTC
