We did some custom work mapping FHIR to openEHR for HiGHmed in the FHIR Bridge. The mappings are just custom code moving data from a FHIR resource instance to an openEHR composition.
I was checking the FHIR Mapping Language, that is used to map HL7 v2.x and CDA to FHIR, and thought that could be used also for openEHR.
Is anybody using that approach?
Hi @pablo . Thanks for the question, I did not know about the Fhir mapping language. Mapping languages are something that I’ve been thinking about, and experimenting with a lot though.
We went through the usual suspects in Ocean (Xslt, code, libraries that does object mapping etc) and we ended up staying with code based mappings. Last time we talked, both @heath.frankel and I were on the same page on that; that it was the best value for money so to speak.
I personally looked at Atlas Transformation Language carefully, and similar alternatives, but I always ended up getting back to code, especially as programming languages kept getting less verbose. The problem with specialised mapping languages are a few: they need an infrastructure to support them (libraries, xslt processors etc). It’s not easy to assign a non specialised developer to this task; with code, you can provide an excel sheet that shows source and target paths and the rest is bidirectional mapping code, which even junior devs can write etc…
I’ll take a look at Fhir mapping language though. I still have not given up on hopes of finding something that may perform better than code
Thanks @Seref I believe, yet to confirm, there is a perfect point of expressiveness vs. standardization between custom code and specific mapping languages, and use cases for both, and maybe the best value for money is just in the middle, some mappings done by code, some done automatically by a declarative mapping language that can be executed. I’m just starting this research!
At Medblocks, we’ve been using Liquid templates to do openEHR to FHIR mapping.
Both the AQL query and the mapping to FHIR is done through these templates. Most notably these are almost always “archetype level” queries so they can be reused across multiple scenarios.
Some screenshots of the mapping of archetypes to Indian FHIR profiles.
AQL to get openEHR-EHR-OBSERVATION-height.v2 data in Liquid
openEHR-EHR-OBSERVATION-height.v2 to ABDM FHIR Observation in Liquid
I guess the FHIR mapping language in this situation is just like any other templating language. Not sure how well it’s being maintained and supported though.
Liquid seems to run on most programming languages and is well supported. Microsoft also did their CCDA and HL7V2 to FHIR mapping in liquid, so we went this way.
Hi @Sidharth_Ramesh though it works for simple cases, because this is basically a smart string builder, it’s purpose is helping on the GUI.
In openEHR <> FHIR mappings, specially complex ones with data transformation and code lookups, a good practice is to design the mappings model-to-model (profile-to-template), then the implementation hopefully can use the models mapping spec, that is why the mapping language could be useful, specially when a mapping language already exists for one of the models and it’s a standard thing there. Liquid templates, smarty, plates or similar are not mapping languages and are not standard.