FHIR Chat · R4 -> STU3 "backport" extensions

Stream: implementers

Topic: R4 -> STU3 "backport" extensions

Kevin Mayfield (Nov 15 2018 at 11:35):

I looking into backporting Encounter.serviceType from R4 to STU3. I don't think this has been done (or I can't find the extension), are their examples of STU3->DSTU2 backports I could use as a basis?

Lloyd McKenzie (Nov 15 2018 at 11:52):

On our (Grahame's :>) list of things to do prior to publishing R4 is the definition of extensions for R3 to support new elements introduced in R4. So in theory they should be available before R4 is published.

Kevin Mayfield (Nov 15 2018 at 12:27):

cheers. I think the only part that will change on our server is the url of the extension and so we know enough to develop (a prototype).

Grahame Grieve (Nov 15 2018 at 13:14):

done - see http://build.fhir.org/versions.html#extensions. What I still have to do is generate the packages

Michael Lawley (Nov 16 2018 at 12:25):

the extensions will then allow for loss-less round-tripping?

Lloyd McKenzie (Nov 16 2018 at 12:53):

Insofar as the types of changes permit, yes. There's no requirement that the changes between versions allow for such round-tripping so it won't always be possible.

Michael Lawley (Nov 16 2018 at 13:03):

I'm thinking R4 -> STU3 -> R4 with no mutation of the STU3 resource along the way. But the catch is if these extensions only address new elements as opposed to semantic drift of existing elements (eg where a STU3 element value gets mutated when converting to R4 and the mutation is not reversible)