Stream: implementers
Topic: STU3 -> DSTU2: "backport" extensions
Josh Mandel (May 06 2017 at 09:34):
Just talking with @Danielle Friend and @Jenni Syed about how they're "backporting" some new STU3 elements like MedicationStatement.category into their DSTU2 resources, using extensions. Turns out we don't have any standard urls for these extensions.
Could we get away with something cheap like a convention for standardizing these backported extension URLs? Like http://hl7.org/fhir/StructureDefinition/backport- + dasherized resource path?
So in this scheme, STU3's MedicationStatement.category would be backported to DSTU2 ashttp://hl7.org/fhir/StructureDefinition/backport-medicationstatement-category...
Thoughts?
Michele Mottini (May 06 2017 at 09:36):
Sounds good to me
Grahame Grieve (May 06 2017 at 09:43):
it would be better for it to be http://hl7.org/fhir/StructureDefinition/extension-[path] where path is an exact literal e.g. http://hl7.org/fhir/StructureDefinition/extension-MedicationStatement.category
Grahame Grieve (May 06 2017 at 09:43):
I could generate them and post them all.... but they would be in STU3 format, not STU2
Josh Mandel (May 06 2017 at 09:53):
I'm not so much worried about having actual hosted StructureDefinitoin content, as having a standardized URL
Josh Mandel (May 06 2017 at 09:53):
OK ,if that patterns works better, that's great
Josh Mandel (May 06 2017 at 09:53):
I'll submit a GForge issue.
Josh Mandel (May 06 2017 at 09:57):
Filed GF#13323
Grahame Grieve (May 06 2017 at 11:21):
it's something we say that you should do - publish definitions. And they would get used by the infrastructure
Josh Mandel (May 06 2017 at 11:23):
Oh, I totally agree! It's just that it's not the part I'm worried about (and if they were STU3 structuredefs... well, that's the same as all standards extensions that a DSTU2 user would try to resolve)
Grahame Grieve (May 06 2017 at 11:27):
I'll see if I have time to generate them all today
Brian Postlethwaite (May 07 2017 at 13:10):
+1 Great idea
Danielle Friend (May 08 2017 at 10:54):
So once those are generated, can I, in my DSTU2 Medication* resources, point to this url officially? Or is there another step I need to take?
Josh Mandel (May 08 2017 at 10:58):
You should be able to jump right in. (Today, when you use an internal extension for this information, are there additional steps you take to document it?)
Michael Donnelly (May 08 2017 at 11:11):
I like it.
Danielle Friend (May 08 2017 at 11:13):
Cool. For this case, I wanted to make sure no additional documentation would be needed to explain the DSTU2 - STU3 crossover, but yep, since it is just a URL, it sounds like I'm good! Thanks for confirming for me!
Jenni Syed (May 08 2017 at 11:14):
This is great. Thanks!
Danielle Friend (Sep 12 2017 at 15:13):
@Grahame Grieve is this still something you're planning on generating?
Grahame Grieve (Sep 12 2017 at 15:25):
Yes. It is. Sorry for not dong it yet
Danielle Friend (Sep 12 2017 at 15:58):
Thanks Grahame!
Jenni Syed (Apr 24 2018 at 20:44):
To bring up an old conversation again... I was trying to track down documentation around this is in the spec but couldn't find it. We have another field we're backporting and I was hoping to use the standard URLs instead of our own extension. @Grahame Grieve @Lloyd McKenzie where did this land?
Jenni Syed (Apr 24 2018 at 20:45):
Last conversation on GForge agreed, but I think I'm missing where it is in STU3 and R4
Lloyd McKenzie (Apr 24 2018 at 21:08):
Where we'd landed was http://hl7.org/fhir/R4/StructureDefinition/SomeResource.element.path for R4 elements you want to pre-adopt in R3, R2, etc. But we haven't actually defined these or made them available in a form that IGs can leverage them. Can you submit a change request?
Jenni Syed (Apr 24 2018 at 21:17):
R4 only or is it also for STU 3 to DSTU 2 (the original use case)?
Lloyd McKenzie (Apr 24 2018 at 21:19):
It'll be for R3 stuff for use in R2 too. (I don't know that we'd bother with R2 stuff for use in R1)
Jenni Syed (Apr 24 2018 at 21:30):
Yeah, no need for R1 as far as I know :)
Jenni Syed (Apr 24 2018 at 21:37):
GF#16015 logged. Wasn't sure about R4 to R2 now that time has gone on since the original discussion :)
Lloyd McKenzie (Apr 24 2018 at 21:45):
I would think that the R3 and R4 extensions combined should allow forward-compatible extension of R2 models with whatever is needed.
Grahame Grieve (Apr 24 2018 at 21:56):
sorry, this was one of 2 or 3 big tasks that missed the boat. It's still slated to happen some time
Grahame Grieve (Apr 24 2018 at 21:57):
the paths will be /DSTU2/, /STU2/, /R4/ since these are already locked in stone on the web site
Grahame Grieve (Apr 24 2018 at 21:57):
(well, the first 2 are)
Lloyd McKenzie (Apr 24 2018 at 22:01):
Presume you meant /STU3/
Lloyd McKenzie (Apr 24 2018 at 22:02):
And the /DSTU2/ ones would be elements in DSTU2 that got punted from R3 for downgrade? (I don't think we need to worry about upgrade)
Grahame Grieve (Apr 24 2018 at 22:03):
yes to both
Jenni Syed (Apr 24 2018 at 22:08):
Thanks!
Danielle Friend (Jul 06 2018 at 21:22):
@Grahame Grieve @Lloyd McKenzie Friendly badger on this - do you know when those URLs will be available? Do I have the syntax right? http://hl7.org/fhir/STU3/StructureDefinition/MedicationRequest.category
Lloyd McKenzie (Jul 06 2018 at 21:50):
The syntax looks right. The creation will presumably be part of Grahame's work on setting up mappings which probably won't happen until the changes are done being made.
Grahame Grieve (Jul 06 2018 at 21:53):
it has to be soon; it's one of the big tasks on my urgent list. It's just that this is a long list
Grahame Grieve (Jul 27 2018 at 23:08):
ok: http://build.fhir.org/versions.html#extensions
Grahame Grieve (Jul 27 2018 at 23:08):
I'll actually generate the packages if there's consensus around the rules
Vadim Peretokin (Jul 30 2018 at 06:55):
FHIR DSTU2 3.0 is that meant to say 1.0?
Grahame Grieve (Jul 30 2018 at 07:00):
yes it is.
Vadim Peretokin (Jul 30 2018 at 07:04):
I'm confused by This technique can be used with all versions of FHIR, including R2 and R3 + Note that this extension framework only applies back to DSTU2. Is it trying to say that you can use an element from any version of FHIR , only in DSTU2?
Grahame Grieve (Jul 30 2018 at 10:32):
well, it doesn't extend back to DSTU1
Vadim Peretokin (Jul 30 2018 at 10:57):
Ohh I misread that, missed back to. Ok.
Jenni Syed (Jul 30 2018 at 15:53):
I think the only change from previous conversation is using the major.minor instead of the "text" (DSTU2, STU3)? We'll have one URL to update in prod for this, I know this is more in line with the versioning management direction :) Just waiting for the DSTU 2 != 2.0 confusion :)
Grahame Grieve (Jul 30 2018 at 18:35):
yes that's the main change - in line with general version management
Lloyd McKenzie (Jul 31 2018 at 14:39):
Will the extension packages make 'standard' extensions available too? For example, if there's an extension defined in R4 and I want to downconvert an instance to R3, I'm going to want that extension to be useable in R3 profiles too.
Grahame Grieve (Jul 31 2018 at 20:12):
I don't know. I didn't think that through
Lloyd McKenzie (Jul 31 2018 at 20:43):
Ok. DaVinci would sort of like some of the R4 extensions available in R3 when we publish our dual version IG in the upcoming ballot...
Last updated: Apr 12 2022 at 19:14 UTC
