Is someone using the FHIR Mapping Language to map openEHR <> FHIR?

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?

2 Likes

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 :slight_smile:

3 Likes

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!

2 Likes

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.

1 Like

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.

1 Like

Hi. Just to reopen the subject of FHIR<>openEHR mapping. I notice the FHIRBridge has removed all code that suggested the openEHR->FHIR direction. Are there any ideas out there around a two way solution? It seems a difficult problem.

I did the openEHR → FHIR mappings on the FHIR bridge for get and search. It is difficult if the FHIR profile and the openEHR template have mismatches for the mappings. For instances, having a set of codes in one (e.g. profile) that doesn’t match exactly the set of codes for the same concept in the other (e.g. template). That means that if a FHIR profile is given, then the corresponding openEHR Template should be designed considering the profile. Or, if the openEHR template is given, the FHIR profile should be designed considering the template.

Technically it doesn’t have any problems, data mappings could be done in both ways, the issue is the semantics behind the data. You won’t find a tool that actually makes mappings between any FHIR resource and openEHR composition. Thought with some code generation techniques it would be possible for taking any FHIR resource and generate a valid openEHR composition instance with all the data from the resource, though for that to work in an openEHR CDR, you will need the template too. With the composition instance alone you can’t do much. So, each mapping should be designed and developed in a case by case way. If done correctly, especially the profile → template → profile mappings, the rest is just time.

To start, you just need the set of profiles/templates that you want to be mapped, then start working on the models, then the mappings, then the code and testing.

2 Likes

Thanks for the reply Pablo. I’ve been using your pull request as the basis for two way mapping as a proof of concept for specific calls to replace a FHIR server. So thank you for that also.

1 Like

Hi @Sidharth_Ramesh
do you have a github repo for FHIR → EHR using liquid?
If there is any, could you please share ?

Regards

1 Like

Hey @Ohia_George unfortunately this is not an open repository. I will let you know if we do open anything up to the public.

Ok, noted.