Stream: OpenHIE
Topic: Data extraction for web
Matt Berg (Dec 15 2021 at 02:34):
@Jing Tang @Benjamin Mwalimu @Francis Otieno putting this here until we have a FHIR SDK thread. Jing - we are close to having the ability to view a Questionaire in the web, fill it out and view the QR. We don't have a clear pathway to supporting data extraction yet. It would be cool to explore if we can use the data extraction libraries in the SDK and use them as a microservice or some kind of thing to wrap HAPI or GCP, etc. Just wanted to throw this idea out there so it was captured. If anyone knows of any work in JS or java for data extraction we can look at please let us know too.
Richard Stanley (Dec 15 2021 at 18:00):
I agree. I went down the definition-based extraction route a bit before finding no open source implementations that can perform the operation by API.
Jose Costa Teixeira (Dec 15 2021 at 20:15):
I'm using matchbox
Jose Costa Teixeira (Dec 15 2021 at 20:19):
(so the extraction is at the server). @Matt Berg do you mean an API that can be called locally as opposed to the REST API?
Matt Berg (Dec 15 2021 at 21:23):
Is there a REST API? The scenario we have is we have the ability via web to fill out a Questionaire and submit a questionnaire response. We would like to be able do extraction via StructureDefs, definitions, etc. We don't know of a way to currently do that. I don't think HAPI or other FHIR stores provide that.
Jose Costa Teixeira (Dec 15 2021 at 21:26):
https://github.com/hl7-be/matchbox
Jose Costa Teixeira (Dec 15 2021 at 21:26):
This is work in progress
Richard Stanley (Dec 15 2021 at 21:33):
Matchbox supports structure map extraction, not definition-based.
Jose Costa Teixeira (Dec 15 2021 at 21:37):
Correct. I'm with you on the definition-based extraction. It is functionally less than structuremap based, and is not implemented broadly
Richard Stanley (Dec 15 2021 at 21:40):
Indeed. I think it's also easier and portable because it can live within a Q or QR.
Richard Stanley (Dec 15 2021 at 21:41):
Btw, on structure map-based, is there tool that will evaluate it quickly without having to submit it to matchbox? Like a plugin or one-liner?
Jose Costa Teixeira (Dec 15 2021 at 21:42):
That is the Work-in-progress bit :)
Jose Costa Teixeira (Dec 15 2021 at 21:44):
I am using a static page that
a) lists all the questionnaires in the server
b) when a user selects one, it renders the questionnaire
c) when the user presses "extract" it gets the structure map that is associated with the questionnaire
Richard Stanley (Dec 15 2021 at 21:44):
nice
Jose Costa Teixeira (Dec 15 2021 at 21:45):
Doesn't do much about tedious work to do structuremaps, but helps prototype and evaluate
Carl Leitner (Dec 15 2021 at 22:43):
As far as I know, there is no open source definition based extract tooling. We've also run into some practical limits with that when dealing with multiple resources and cross-references. I think we need to move to fhir mapping language /structure maps.
Matt Berg (Dec 15 2021 at 23:20):
Thanks for sharing Jose! Is this a wrapper of HAPI? Want to make sure we can keep upgrading HAPI as needed. We've built a web interface based on a library we got from the Norwegian health institute that allows us to do web based data entry of questionnaires so this looks like a perfect compliment. @Carl Leitner we want to explore if we can use kotlin libraries from the SDK too to support extraction.
Matt Berg (Dec 15 2021 at 23:22):
Definition based though has advantages in that it allows people to include in questionnaires . I realize it's not as robust but for people wanting to build simple case management apps I don't think that should be overlooked.
Jose Costa Teixeira (Dec 16 2021 at 09:32):
matchbox is built on HAPI, yes
Carl Leitner (Dec 16 2021 at 12:02):
with what @Vitor Pamplona is doing on the android CQL engine, that should support CQL extraction w/o too much effort. just need to figure out API calls on the FHIR SDK. Flagging for @Jing Tang as well.
Matt Berg (Dec 16 2021 at 12:50):
Is that work being done in the SDK? I think it would be good to discuss general approaches around extraction and how we want to make them accessible to different kind of users.
Vitor Pamplona (Dec 16 2021 at 13:30):
CQL is running quite well on Android with the latest PR merge on the CQL Engine. But all FHIR libs are still quite heavy for phones, even flagships.
Matt Berg (Dec 16 2021 at 17:44):
Yea the CQL engine stuff we've been running (outside of the evaluate in the SDK) is pretty heavy. This is something we'll need to really profile and see if there is room for optimizations with the FHIR SDK over the long run.
Vitor Pamplona (Dec 16 2021 at 19:10):
Long term pitch: Let's ban the use of Reflection on FHIR in favor of code generation. That includes compiling CQL into JVM code. That will solve 90% of the performance issues, finally putting FHIR projects into the "environmentally conscious" bucket.
Carl Leitner (Dec 16 2021 at 19:12):
I'm okay with this. As long as the CQL hangs around. We don't want to force Java on people. For example, there is a JavaScript implementation of the CQL engine
Vitor Pamplona (Dec 16 2021 at 19:15):
oh.. Yes... Ban reflection on the FHIR libs written for Java only.
Matt Berg (Dec 16 2021 at 20:17):
I brought up Kotlin though as I know we are doing data extraction in kotlin right now. We can run that on servers and I believe it can compile down to JS too. So was just thinking about a way to have consistent support across both the SDK and server for extraction
Last updated: Apr 12 2022 at 19:14 UTC
