Stream: implementers
Topic: Versionless FHIR
nicola (RIO/SS) (May 08 2017 at 10:13):
I think, we have to exercise versionless FHIR as soon as possible. Some part of FHIR and libs are designed with "closed world assumption", which is not very compatible with backward compatability. Just a simple question: how FHIR will handle new elements addition without breaking existing systems and tools?
nicola (RIO/SS) (May 08 2017 at 10:22):
Let's define - "what means backward compatible" @Grahame Grieve - "old client could work with new servers?", "new clients will work with old servers"?
Grahame Grieve (May 08 2017 at 10:24):
read the spec first. See http://build.fhir.org/versions.html
nicola (RIO/SS) (May 08 2017 at 10:37):
May be we have to talk not about versionless, but about multi-version FHIR eco-system - how multiple version would coexist?
Lloyd McKenzie (May 08 2017 at 10:38):
Agree that the reference implementations definitely need to be adjusted (and tested) to work with our planned forward/backward compatibility rules
nicola (RIO/SS) (May 10 2017 at 13:39):
Discussion about where to add fhirVersion info - is a good example, that current design of FHIR is not enough flexible to do back-porting and backward compatibility. I have idea how it could be done: just by extracting Element into separate resource from StructureDefinition, potentially it would be easy to back-port new Elements to previous releases. I understand, this require redesign most of libraries & tools, but may be better to do it now, before versions hell :)
Grahame Grieve (May 10 2017 at 13:47):
you;re just moving the deck chairs around
nicola (RIO/SS) (May 10 2017 at 13:56):
@Grahame Grieve do you mean Elements and Extensions?
nicola (RIO/SS) (May 10 2017 at 14:02):
What nice property, i see, about this - you could publish new domain releases just as a package of extensions of previous version - does not this look like versionless?
Jenni Syed (May 10 2017 at 14:42):
I think it's going to be hard enough to do forward and backward compatibility when we hit normative (and we have some lead time).
Jenni Syed (May 10 2017 at 14:43):
I agree with Grahame - this backport doesn't solve the core issue behind this. It could actually make some things harder
nicola (RIO/SS) (May 10 2017 at 15:01):
@Jenni Syed the reality will be multi-version eco-system for FHIR - so what i fill - FHIR should be designed as an open system, which means, for example, you should be able to add new elements or ignore unknown without breaking working software
Jenni Syed (May 10 2017 at 15:02):
That's great in theory, but very hard in implementation.
Jenni Syed (May 10 2017 at 15:02):
eg: Even if FHIR spells out what is considered forward and backward compatible (and it will need to be very specific about this)
Jenni Syed (May 10 2017 at 15:02):
It also needs to tell clients what they need to do to handle this
Jenni Syed (May 10 2017 at 15:03):
For example, some JSON libraries default to blowing up when a new element is found
nicola (RIO/SS) (May 10 2017 at 15:03):
Yes, this is challenge - tools & libs should be designed for it
Jenni Syed (May 10 2017 at 15:03):
My guess is that there will be enough work to do in the community to get to this on "normative" for both acting clients and servers... and that then trying to redefine this on an existing deployment...
Jenni Syed (May 10 2017 at 15:04):
That is guaranteed to cause issues - you never told those apps or servers this was ok. And they're already running in prod
Jenni Syed (May 10 2017 at 15:05):
keep in mind that the tools and libraries are equivalent to "all XML, JSON, HTTP libraries in all languages that someone may choose to use"
Jenni Syed (May 10 2017 at 15:05):
updating reference implementations is one thing, but that won't cover all apps nor servers
nicola (RIO/SS) (May 10 2017 at 15:07):
This issue was somehow solved for ORMs - which works with changing schema - so there are some strategies to hack it
nicola (RIO/SS) (May 10 2017 at 15:07):
Isn't FHIR like database schema?
Lloyd McKenzie (May 10 2017 at 15:12):
In the near term, we can change names, change scope, change cardinalities, change constraints and do all sorts of breaking changes between releases - and we're not going to give up the right to make those sorts of breaking changes until a resource becomes normative - which could be 8+ years from now for some resources
Jenni Syed (May 10 2017 at 15:13):
@Lloyd McKenzie Agree
Jenni Syed (May 10 2017 at 15:15):
@nicola (RIO) Yes, you have very similar constructs for JSON and XML to object models (assuming that there's an OO language behind the scenes). I'm not sure I would say ORMs are "solved" - there are a lot of issues still with it, and they vary by language. And sometimes your database gets to be garbage from a good relational design perspective if you start with OO and go to DB
nicola (RIO/SS) (May 10 2017 at 15:16):
@Lloyd McKenzie every such breaking change will be tears & blood of engineers :(
Jenni Syed (May 10 2017 at 15:17):
I personally would rather pay that price than have a spec that's hard to implement/understand, knowing how many challenges we face implementing some of the more draft resources today
Jenni Syed (May 10 2017 at 15:17):
Once we hit normative, we'll have enough challenge making sure we don't break people with backwards compatible changes :)
Jeffrey Danford (May 10 2017 at 15:20):
There were suggestions to use existing structures (extensions, tags) to convey version information and wouldn't introduce breaking changes. Am I missing something since everyone's locked on adding a new element?
nicola (RIO/SS) (May 10 2017 at 15:24):
Back-porting FHIR version is just an show case of compatibility between releases - yes, tags & extensions are compatible, but my question was, why do not make elements also portable?
Jeffrey Danford (May 10 2017 at 15:29):
We're in the same boat as @Jenni Syed - we have production environments and we'd really prefer finding something valid we can do without significant re-engineering, at least not for something as superficial as this.
Lloyd McKenzie (May 10 2017 at 15:29):
@nicola (RIO) Yes, but that's what "trial use" means. If an engineer signs on at this point, they accept that blood and tears are the price of early access/use and ability to influence. The alternative is the worse blood and tears of working around something that doesn't work - and often working around issues in inconsistent and non-interoperable ways.
Lloyd McKenzie (May 10 2017 at 15:30):
@Jeffrey Danford We're absolutely not locked on adding a new agreement. There's been no decision. Merely an exploration of issues and potential options.
nicola (RIO/SS) (May 10 2017 at 15:32):
I'm mostly talking about future - after first normative release, there will be more other normative releases - and ability to be backward/forward compatible on elements level will give engineers more options to plan and implement migrations and integrations
nicola (RIO/SS) (May 10 2017 at 15:33):
interoperability between FHIR versions :)
Lloyd McKenzie (May 10 2017 at 15:50):
@nicola (RIO) After the first normative release, only a small set of resources will be locked. Most/all of the clinical resources will still be subject to change for at least another 18 months (and for some, maybe 5+ years - some resources needed for public health and other edge spaces may not show up for the first time until R5 or R6). Certainly the intension is that for a "locked down" resource, there will be a mechanism to add new elements in a backward compatible way (for those systems that are designed to support that). But we'll still be adhering to the 80% rules. Local needs will still need to be met by extensions.
Mattias Flodin (May 11 2017 at 06:00):
Just want to say I find this to be a really interesting discussion. I'm currently evaluating the use of FHIR as the data model and API for a central integration hub, through which multiple systems can be reached. With 300+ connected systems it is obvious that not all of them can be communicating using the same FHIR version. I have yet to come up with a plan for handling portability between versions.
Mattias Flodin (May 11 2017 at 06:10):
probably it will be the responsibility of the hub to backport v2 resources for v1 clients. May be harder if a v1 client pushes a resource that has additional required attributes in v2
Grahame Grieve (May 11 2017 at 06:45):
right now, that will be very difficult because there are really incompatible changes between FHIR releases. Over time, this will reduce - it already has for many resources (e. g. 2 minor changes in patient between R2 and R3) , and once we call the content normative, there won't be any.
Grahame Grieve (May 11 2017 at 06:46):
but we have scripts for R2 <-> R3 conversion, and will maintain those going forward - so I would solve this problem by doing version conversions on the portal
Last updated: Apr 12 2022 at 19:14 UTC
