Stream: implementers
Topic: meta.versionId
Abbie Watson (Mar 21 2017 at 19:20):
Is it appropriate to put the schema version in meta.versionId, or is that only for versioned history of a specific history? Where is the expected place to store in a resource that it's schema version 1.6.0, for example?
Jenni Syed (Mar 21 2017 at 19:30):
The meta is intended to track the history of a specific resource. EG: I created MedicationStatement/abc, then updated it, then updated it again. the meta.versionId on MedicationStatement/abc must be different for each of those instances
Jenni Syed (Mar 21 2017 at 19:32):
ie: meta.versionId = "0", next meta.versionId="1", final meta.versionId="2" (though they can be any type of version, alphanumeric etc, and don't need to be an incrementation like this)
Jenni Syed (Mar 21 2017 at 19:32):
As FHIR is right now, if the conformance on a server states version 1.6.0, the resources exposed would be assumed to be of that version. I don't think we have anything defined in core to indicate what a specific resource's FHIR version is
Josh Mandel (Mar 21 2017 at 20:19):
+1 @Jenni Syed. FHIR doesn't have a standard approach to label instance data in this way (it's certainly something that's been discussed).
Abbie Watson (Mar 21 2017 at 20:22):
Hmmm. Thank you for the clarification, Jenni. Seems like we're going to need to have an internal extension then. We're reaching the point where we have two or three or more different apps pointing at a single database using FHIR as our database schema. So, we're considering intra-app interoperability, with the database as a wire persistence cache. Need to start managing schema migrations. I'll probably go with meta.fhirVersion then. (Unless there are any other recommendations.)
Igor Sirkovich (Mar 21 2017 at 20:34):
You might wish to have a look at resource tags: http://build.fhir.org/resource.html#profile-tags
Grahame Grieve (Mar 21 2017 at 20:48):
different apps are supposed to suppot different versions?
Grahame Grieve (Mar 21 2017 at 20:48):
like on the fly?
Abbie Watson (Mar 21 2017 at 21:28):
We have a really fast turn-around time of getting an app up-and-running in about 6 to 12 weeks. So we have a number of deployments which have been writing down v1.0.2 Patients, Practitioners, Questionnaires, and other resources for the past year. But now we have the Interface Engine, Practitioner Directory, and Clinical Decision Support apps going online; but they're on v1.6.0.
Put another way, we're trying to point a fhir-1.0.2 app and a fhir-1.6.0 app at the same database. Trying to figure out the details of how to do that, and not completely bork things.
Grahame Grieve (Mar 21 2017 at 21:42):
well, if it was me.... you're going to need a translation layer somewhere. the changes between r2 and r3 are deeper than just 'changing the format a little'
Grahame Grieve (Mar 21 2017 at 21:42):
queries are different... so right now, you'd need to either (a) do different endpoints or (b) use some kind of header or url parameter
Abbie Watson (Mar 21 2017 at 23:04):
oooh, now that's an interesting idea. Use the meta.fhirVersion to build up a virtualized url, and have the database driver use the same translation layer that the REST endpoints do for r2 and r3 endpoints. Isomorphic code reuse. Excellent. That's exactly what I was looking for. Thank you!
Paul Knapp (Mar 22 2017 at 10:55):
Do you mean the CapabilityStatement.fhirVersion associated with the receiving endpoint?
Abbie Watson (Mar 22 2017 at 16:26):
No, I'm (now) talking about an extension to Meta or DomainResource that provides a lightweight capability field on a per-record level. It's for database schema migrations and scenarios involving apps with different CapabilityStatements accessing the same JSON database.
Lloyd McKenzie (Mar 22 2017 at 16:33):
Why use an extension when you could use a tag?
Abbie Watson (Mar 22 2017 at 16:40):
Well.... extensions are easy, it would keep things semantically consistent, and performance. Doing a quick check that CapabilityStatements.fhirVersion is equal to Meta.fhirVersion will be a lot more performant than looping through tags... particularly if the collection has millions or billions of records that have been created by from apps with different CapabilityStatements. Also, I'm not sure if I can put an index on the tags, since they're within an array. Might be able to; but I'll need to research it.
Paul Knapp (Mar 23 2017 at 11:16):
To achieve consistence and efficiency then I suggest you propose that meta.fhirVersion be an element. I see other uses including systems which process multiple versions.
Lloyd McKenzie (Mar 23 2017 at 15:06):
We absolutely *don't* want instances declaring what version they are in general practice. While this is necessary in some environments during the STU2 phase, it's counter to our objective of having a versionless specification in the normative phase.
Paul Knapp (Mar 24 2017 at 15:09):
Given that even after normative new resources will flow through the STU process, wouldn't it be a good idea to have a defined place/tag/extension to hold the version rather than encouraging people to make up their own?
Lloyd McKenzie (Mar 24 2017 at 15:29):
If new resources flow in that you don't support, you'd treat them in the same manner as you'd handle resources you receive now that you don't support - no need to have a version to do that.
Paul Knapp (Mar 26 2017 at 07:07):
I don't think the issue is resources which people don't support but rather resources that people do support which are undergoing change.
Lloyd McKenzie (Mar 26 2017 at 15:55):
But once things are normative, the only changes permitted are backwards-compatible ones.
Last updated: Apr 12 2022 at 19:14 UTC
