FHIR Compatibility

Issue

There are a number of things that need to be nailed down to define application expectations in terms of backwards and forwards interoperability:

1. Search parameters can be defined by local implementations in the same namespace as the “official” search parameters. The result is that introducing new search parameters in the future could collide with existing local parameters
   1. Recommend requiring that local search parameters be required to have a specific prefix (e.g. ‘_’)
2. CS coded elements are defined as fixed enumerations, including validation in the schemas. In the future, we may need to add additional codes to some of these enumerations. How do we expect old systems to respond?
   1. Require to accept and ignore?
   2. Require to reject?
   3. Case by case/system’s choice?
3. We occasionally have min-Occurs 1 elements that have a choice of data types or resource types. In the future, we may introduce additional data types or resource types into the allowed set. How do we expect old receivers to handle receiving a new element they weren’t expecting (and didn’t get an element they were expecting)
   1. Same issue can occur where we have a required element that has a single type but in the future we choose to add an additional type. (Presume we can never drop a type?)
4. At the moment, our schemas enforce that only the declared elements are specified. However, in the future, additional elements could be added. Are we going to promise to add them at the end or could they appear anywhere? How are systems expected to behave when they receive unexpected elements? (They won’t pass schema validation, and because the schemas have optional elements, there’s no way to make them pass.
5. Are we allowed to loosen or tighten the minimum cardinality and if so, how do existing implementers cope?
6. Can we deprecate an element? Do we still expect implementations to populate them? Forever? For a fixed time?
7. Can conditions (constraints) be added or changed
8. Can mustUnderstand or mustSupport be changed?
9. Can vocabulary bindings be changed for non-“code” elements? What if it’s a Coding?
10. Can the source resources or returned resources by an Event be changed?
11. Profiles – even more questions about what can change in a Profile.
12. Are implementations allowed to define their own extensions to the REST operation parameters (or are those considered to be independent services and not RESTful FHIR services?
13. Given that we’re seeking *lots* of implementers for the DSTU(s), and we’re hoping that at least some of those implementations will be production systems, how are we going to manage interoperability with new DSTUs and eventual normative version, given that backward compatibility rules are looser and we don’t yet have a mechanism for identifying what version you’re seeing
14. When we add new elements to “core” that happen to be “must understand”, how does that get communicated in the instance?
    1. When does this occur – only after normative, or between DSTU releases? Should we start doing it now?
15. Should we consider declaring “mustSupport” on core elements?

Resolution (to date)

1. Let people know that we are trialing inter-version compatibility during the DSTU process
2. No guarantee of consistency between DSTU versions while we work this out
3. expectation of breaking changes between DSTU and Normative edition
4. we will clarify the methodology implications through the DSTU process
5. FHIR project team will draft working guidelines to test through that process