Build Resources using FHIR Path

[Ma P]

Hey everybody,

I am trying to build Patient Resources based on FHIRPaths. More specifically, I have web-service that should receive the ability to define a FHIR Mapping (using FHIR Path) for internal datasets and create Patient Resources based on this mapping (i.e. a collection of FHIR Paths). I am using HAPI 5.2.0 with FHIR R4 for that.

Previously to FHIRPath I have used the (deprecated?) Terser, which allowed me to create new fields using the `getValues()` method. With FHIRPath, there is no such method as far as I can see. I tried around with using the FHIRPathEngine and iterating through ExpressionNodes to create a Resource, but I am unable to a value by String. Right now, I cast an empty Resource as `Base` and search for the element I want to write using `Base.addChild()`. On each "leaf"-Element, I get a FHIRException like `Cannot call addChild on a primitive type Address.city`. I had bad luck with catching the exception and trying to set the property I want to set (in the case of the example exception: `city`). I assume that there is another way to approach this problem?

I know that FHIRPath may not be the best fit to create a real mapping (as the main intention is to read Resources, not write them), but for me it seems to be the best fit.

Any suggestions?

Thanks!

- Marcel

[Ma P]

PS: I forgot to attach my current working state, I uploaded it as a code-snippet here: https://gitlab.gwdg.de/-/snippets/453

[Ma P]

Hey everyone,

I was able to "solve" it in the meantime by checking out the Parser methods of HAPI. I created a (rather incomplete) builder for Resources using FHIRPaths here. (link to a public GitLab instance)

This Java class allows to create FHIR Resources based on a Map for FHIRPath -> value mappings and includes handling of "where" functions. There are many other functions in FHIRPath, but for now I did not see any need to implement those. Maybe this helps someone as a starting point for similar problems.

Cheers

Marcel

[James Agnew]

Wow, this is a really neat approach.

If by chance you wanted to contribute it to the HAPI FHIR project, I'd love to include it in the actual library!

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/27d5759a-6ee0-4d35-8fbc-6a16e7d1255an%40googlegroups.com.

[Ma P]

Hey James,

I would love to contribute! If you could give me some pointer where to put the class, I could quickly prepare a pull request on GitHub.

Note that my generator is fairly incomplete in terms of FHIRPath functions, but getting the code into HAPI would surely enable some discussion and feedback on that.

Cheers,

Marcel

[James Agnew]

Good question. I guess probably the hapi-fhir-validation module would be the path of least resistance, given the dependency on the R4 FHIRPath engine, and probably in an R4 specific package since this code would currently only work for that version.

We do have a version-independent abstraction over the FHIRPath engine in the IFhirPath interface, which lives right in hapi-fhir-base. If we could get enough of the required functionality into that interface (and probably new ones to handle things like ExpressionNode in a version independent way as well) we could move this into hapi-fhir-base. I have no idea how hard this would be though..

Cheers,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/1c06d620-393d-46eb-960b-ef35a034cab6n%40googlegroups.com.

[Ma P]

Done here: https://github.com/hapifhir/hapi-fhir/pull/2310

I added the Test Cases that I had lying around for the class (hooray to test-driven development). I think there is quite some room for improvement I will try to add any ideas that come to mind regarding FHIRPath generation to that class to make it more complete. Also, I will try to look at IFhirPath and any class that could make the generator more version independent. No guarantees though, as HAPI can be pretty complex in that regard.

Cheers,

Marcel

[Ma P]

Hey everyone,

I have experimented with the generator a little bit. I found out that creating a new generator can be pretty costly, especially creating a new FHIRPathEngine. Especially this line seems to generate quite some load on the CPU. Does anyone have a good hint on how to deal with this (create a Factory that returns always the same Class?)

In my use case, I use the generator in a Web Service to create new Resources based on FHIRPaths. I reduced the number of created FHIRPathResourceGenerators instances and was able to decrease the response time by factor 5. Quite an impact!

Cheers

Marcel

[Jean Claude Correale]

Hi Marcel

I checked out the FHIRPathResourceGenerator and I think I found a similar problem. In my case, it turned out the bottleneck was this invocation (which some times, but not always, took a lot of time)

this.ctx.getResourceDefinition(resourceClass)

I solved it, for now, by introducing a cache of resource definitions so that such invocation wasn't made for each resource generation. 

I also tried to male the generator class non-generic and stateless so that the same instance can be used to generate multiple resources of different types.

I was wondering wether the generator was still under active development, we're using FHIR for a project and I find the fhir resource generator an awesome idea to simplify the usage of FHIR in our applications.

My use case is pretty similar to yours so I think we might be able to collaborate if you like.

Cheers to everyone on the group, 

and thank you all for the awesome HAPI project!

Jean Claude

[Ma P]

Hi Jean Claude,

sorry for the late reply, had quite a lot on my plate lately.

I think it is awesome that the Generator works for you as well! Always cool to see open source in action :-) Right now I am not actively developing the Generator, as - for my purpose - it does what it needs to do. But I would love to see your ideas and incorporate them into the generator. Making it faster and / or more generic would be great. Let me know if there is anything in particular that I can or should have a look at.

Cheers

Marcel