concurrent support for multiple fhir versions

[olbrich]

It's not unusual to be working in an environment where multiple FHIR endpoints are used and it is unlikely that all of them will be able to upgrade to the latest version of the standard at the same time.

How can we support multiple versions of FHIR at the same time?
@jawalonoski What are your thoughts on how to implement this?

[jawalonoski]

Timely question.

My plan was to:

1. make a copy of the bootstrap code and back port it to DSTU2 structure definitions
2. iterate on that until the generated DSTU2 models function and pass a clone of the unit tests.
3. namespace the DSTU2 and STU3 models, e.g. FHIR::STU3::Patient and FHIR::DSTU2::Patient
4. Alias FHIR::Patient to point to the most recent version by default, then add something like FHIR.use_version(FHIR::DSTU2) or something like that to change the default behavior.

Thoughts?

[olbrich]

1. versioning by the 'DSTU2' style names is going to be awkward. Ideally I'd like to be able to determine which version of code to use based on the Conformance/Capability statement. I'd prefer something like FHIR::Patient['1.8.0'] so I can just pass in the value returned by the remote server to generate the correct model.
2. the fhir_client gem is also going to have to be versioned since the ConformanceStatement itself has changed
3. We are going to need support for more than just DSTU2 and STU3. We have partners working on 1.6.0 and 1.4.0.
4. including the structure definition of older versions is going to make the gem size itself quite large unless they are excluded from the gem package. I'm unclear if they are needed at runtime.
5. It might be difficult to find the precise version of the definitions since I don't think the github repo has tags for the versions... not sure about the master SVN repo.

@bkaney, @jec, @dlanphear9, @wesrich, @johncalvinyoung -- we've discussed this approach internally.. were there other problems that I haven't listed?

[jawalonoski]

@olbrich some responses...

1. I hear you... that looks gross though.
2. Yes.
3. Sigh. We were hoping to just support the latest version of a given release. This complicates things significantly.
4. They are not required at runtime... unless you choose to dynamically load base types in profile validation... which is an area that can use some TLC.
5. Yeah, they are available in SVN without too much suffering.

[dlanphear9]

Yes, we've had a number of discussions around that -

1. The ability to load different versions of resources easily like FHIR::Patient['1.8.0'] also provides the ability for aliasing, so FHIR::Patient['DSTU2'] could be used as well.
2. Agreed
3. see (1) above. That seems to provide the most benefit with the least difficulty of the choices we've looked at.
4. I don't think that's a high priority
5. Good to hear the tags are in SVN. 👍

[arscan]

We will need to support FHIR 3.0.0 pretty soon, since that was recently released and we are starting to see some implementations pop up in the wild. Unless people have been actively working on multi-version models and see that landing here soon, we'll just update this gem from 1.8.0 to the new version in the same way we've done in the past. fyi @olbrich @dlanphear9 @wesrich

[olbrich]

@arscan We are working on a multi fhir version, but it's not ready yet.

[mustmodify]

You may be too far down the road to pivot at this point, but have you considered a factory pattern? Here's an example interface that might appear in config/initializers/fhir.rb

FHIR = FHIRFactory.new('DSTU2')
FHIR::Patient.new(...)

In this case, the FHIRFactory would return an object whose child constants would support the correct version. I hadn't thought this through, but you could probably use const_missing to default FHIR to whatever you thought was the most appropriate version... though on further thought, it would probably be better to force users to be explicit.

This keeps things relatively simple for the 80% case -- applications that support one format. And it makes it also pretty easy for those that support multiple formats. They would just come up with a different constant name.

[olbrich]

@mustmodify the approach we are taking would allow for something similar.

[mustmodify]

Great! I appreciate the work you are doing. Since that could really affect new users' experiences, make sure the README is explicit. I'd be happy to "beta test" your instructions. Thanks again!