Implementation of FHIR Questionnaire Resources and FHIR R5

OpenEMR Development
#1

Well here I am again wanting to contribute new development and finding I need to add structural change to OpenEMR!
Some may not know that I introduced our current R4 support classes and while I could implement new questionnaire endpoints using R4, the R5 version has some great improvements to the resources, especially forms and SDC making building easier.
Another reason for implementing R5 resource endpoints is that since my recent lforms(already implemented throughout) upgrade to the latest version, both R4B and R5 are now supported. How cool is that?

We already know how we need to implement the new endpoints based on our FHIR structure for current endpoints however the introduction of R5 requires some careful planning.

The already generated R5 classes are available from the same project I manually generated the R4 classes however, the pre generated classes offered have a different namespace and dir. tree structure which are meant for a composer include. I opted not to do a composer include with R4 because I didn’t want to rely on that dependency and generated classes from available xsd and configured to openemrs namespace. I also trimmed out some unneeded classes. When I made this decision nobody really cared about FHIR and was left up to me. Not so with R5 where I’m looking for input concerning this implementation. Some questions are:

  • Do we need to maintain the same structure as current R4?
  • Do we want to simply include with composer?

Since the answers to those questions will impact how we implement routing and rest endpoint support classes we have new questions such as:

  • For routing do we add a version to our API URI such as https://localhost/apis/default/fhir/v5/ or maybe or a simpler implementation like https://localhost/apis/default/fhirr5/ or similar. We still maintain unchanged current R4 routes. My preference is add the /v5.
  • Do we want to implement a middleware of some sort to arbitrate versions and still utilizing current endpoints. I don’t want to write that piece, do you?:slight_smile:
  • Do we simply move and refactor current to new version structure in our name space like: OpenEMR\RestControllers\FHIRR5 or OpenEMR\RestControllers\FHIR\R5? My preference.

While I’ll do the generation to use the same namespace and dir. structure of R4 if this is preferred(takes at least4-6hours of work), I’d like to take the projects pre-generated and refactor the namespaces and include as FHIR/R5. or we can include as a vendor resource via composer. I can argued either way but I seek the community developers preference.

Some links:

I do hope that since I’m taking this on that I’m not left hanging because this is an important upgrade to openemr. Not only preparing for future R5 requirements and along with my intended questionnaire form responses CDR integration, this will complete a very powerful end to end questionnaire feature. Think potential assessments with some smarts.

That’s all I can think of at this time.

1 Like
#2

I also prefer the https://localhost/apis/default/fhir/v5/ URL structure. I think we should keep the unprefixed version as the R4 default. US Core 6.1.0 which we have to comply with by 2026 still bases everything off of R4 (thought they’d upgrade to R5 but apparently they don’t when I just checked).

I don’t believe we will h ave to arbitrate between versions if we use different FHIRRestControllers for the R5, if we want to reuse those controllers we will need to have some kind of middleware for translations between versions. Supposedly the HL7 group has some tools for translating between resource versions if the resource has not been declared Normative (trial use, experimental, etc).

I just can’t think of anywhere we actually modified the raw class structures from the initial import w/ R4. I’m not confident on this, but I think we could just use the composer vendor include. If we think we will be modifying the raw resources inside our project then we might as do what we did with R4, but I’m just skeptical based on what we’ve done in the past that we need that.

As far as the FHIR stuff, I know that talking w/ the board there was not a lot of inclination of putting resources into FHIR until the beginning of next year unless more funding was secured for the 2026 ONC certification.

These are my thoughts, I’m not really speaking on behalf of the community or the OpenEMR board, happy to hear others thoughts and views on all of this.

1 Like
#3

Thanks @adunsulag
One issue with the composer include is it includes everything since DSTU 1. This then requires raw size of approx. 180MB to our release compared to approx. 60MB however the current R4 which I trimmed out some bloat is 15MB.
So a resource issue.
However since R5 is just a major release with the next normative being R6 I may be able to get what I want for questionnaires’ from R4B and/or only include those R4B/R5 classes necessary for questionnaires.

1 Like