FHIR R5 Support

[nikzen]

Hey everyone,

I wanted to ask if you already have a rough time estimate about supporting FHIR R5. We are evaluation right now Medplum (and it looks really great!) to replace our current Fhirserver, however we want to already use the FHIR R5, as we see big potential in the changes of Task & List for example.

[codyebberson]

Hi @nikzen - good question. We published a blog post on R5 back in March when R5 was officially released: https://www.medplum.com/blog/fhir-r5

Short version: R5 is not widely used yet. R4 is still the "standard", and likely will be for at least another 2-5 years. While we absolutely want to be mindful of the future, we also want to be pragmatic about serving the most pressing needs of the healthcare community, and right now that is in R4.

We absolutely do intend to support R5. We hope to be good citizens, and promote migrating in a timely fashion. Our R5 plan is roughly as follows:

• Support R4 and R5 in parallel simultaneously
  • All of our database tables, client libraries, and UI components are derived from StructureDefinitions from the spec, so this should be a mostly automated process
  • Some resource types are deeply integrated in server logic, and will require substantial engineering work. Most notable is Subscription
• At a Medplum "Project" level, the project administrator will have to choose the primary version
• To enable migrations, we intend to use FHIR Mapping Language to attempt to automatically convert resources from primary to secondary
  • HL7 has published draft versions of R4-to-R5 and R5-to-R4 conversions. Those are not fully battle tested yet. As they improve and stabilize, we hope to leverage them to accelerate migrations.

If R5 is an absolute "must have", please feel free to reach out to the Medplum team directly at hello@medplum.com. We'd be happy to discuss in more depth.

[nikzen]

Hi Cody,

thanks for your long and detailed answer. I will sent you an email in response :)

Best,

Niklas

[codyebberson]

We've received an uptick in the number of requests about R5 recently, so here are some more detailed thoughts.

• @medplum/fhirtypes
  • Currently, fhirtypes is essentially R4 types
  • Question: Should R5 types be added to the same package? Or should we split them into separate packages?
  • This might seem like a minor decision, but it has ripples throughout the project and all of our customer projects
  • How should we namespace the resources?
  • We could use advanced NPM package exports to support import { Patient } from '@medplum/fhirtypes/r4';
  • What to do about Resource? Should it be namespaced? Or should it be prefixed like R4Resource?
• @medplum/core
  • MedplumClient currently assumes R4 types
  • We could add type params such as MedplumClient<TResource = R4Resource, ...>
  • Or we could add type params to all of the different methods createResource<T = R4Resource | R5Resource>
• @medplum/react
  • This is further evidence for the need for internal types (i.e., InternalElementDefinition over ElementDefinition) so that we can be version agnostic
  • @mattwiller - One thought exercise for you: Are R4 and R5 structure definitions similar enough that we will be able to use the same validator? Or are they so different that we'll need separate parallel implementations?
• @medplum/server
  • There are interesting and challenging requirements here, but the good news is that those should all be internal implementation details without any API breaking changes
  • All new R5 work will be exposed in the /fhir/R5/ URL path
  • The FHIR Mapping Language work is "nice to have", not "must have". Many projects will be ok to be strictly constrained to a single FHRI version