Hi, at CRS4 we have developed a tool called flatehr for converting data to openEHR. It allows to generate compositions in flat format mapping source fields (at the moment XML and JSON are supported) to template nodes. There is also a small script for ingesting the generated compositions to an openEHR server.
It is actually still experimental and absolutely not bug-free. I hope someone can find it useful. Any feedback is welcome!
Mauro,
nice work! Would you like to say something more about how you would like collaboration to work e.g. by people creating pull requests, or should they ask to be on the commit team, create branches etc?
Hi Thomas, collaboration via pull requests is fine for me.
Nice to see so fast response in Issues · crs4/flatehr · GitHub
Now if somebody (e.g. a student project) would program a (ideally source+target-aware) GUI or a code editor extension/mode/languageserver that makes editing the configuration (mapping) file easier, that would be neat…
I agree having a GUI or a code editor (not a thing I considered at first, thanks for the suggestion) would be great, any help for further development is absolutely welcome.
Interesting work and thanks for sharing, Mauro!
I’ve been working on something in the same space for several months now too (Introducing FHIR Connect). Prior I researched existing work and since there’re some conceptual similarities to your work and just in case you never heard about it, you should check out (@rtweed):
GitHub - robtweed/qewd-transform-json-editor: Browser-based editor for developing and testing qewd-transform-json templates (GUI)
GitHub - robtweed/qewd-transform-json: Transforms JavaScript Objects using a Template Object (foundation)
Hi @jake.smolka!
Betters “FHIR Connect” looks nice for FHIR <–> openEHR mappings.
Does it support mapping from arbitrary JSON & XML formats like @mdrio’s flatehr does? If not, is it planned in the future?
Is the specification of the mapping file format published anywhere?
Hi @jake.smolka, qewd seems pretty interesting, thanks for sharing. Definetely I will consider it for future development / GUI.
Hey Erik, I didn’t want to takeover the thread with my FYI for Mauro.
But to quickly answer your questions: No support for arbitrary formats, due to a high degree of utilization of specific attributes of both FHIR and openEHR. The mapping files specs are currently finalized and will published once done.
I agree that a Code editor is possibly a better approach than a pure GUI as inevitably there are more complex mappings that have to be defined and prescribed and it is often easier to do that in code ). Rob’s QWED being a good example. So supported file generation rather than
Our approach in One London was to map xml paths from the source xml instances to a set of target dummy openEHR flat form compositions and just document in a spreadsheet!!
This works pretty well, other than
IMO These are just a lot easier to document in some sort of code or pseudocode, and JS (as per QEWD) does make it easy to intersperse functions and data.
Example from One London
In a project at Karolinska we have tried to decrease the use of Excel as a mapping specification since it tends to fall out of sync with actual source/target-models and mapping code. The approach of trying to make mapping specs both human readable/writeable and machine-readable/executable as in @mdrio’s Flatehr and @jake.smolka’s “FHIR connect” seems to have potential regarding maintainability. Simplified (easier to read) documentation (HTML/PDF/Excel) could possibly later be autogenerated from the actual spec when really needed.
A cumbersome part of mapping is the cut&paste of paths etc from source and target. Flatehr seems to solve the target mappings by autogenerating a skeleton including target paths, that reduces work a lot (it is easier to delete unneeded parts than hand crafting or copying target paths correctly).
(The other part is creating paths/filters/queries for pointing out json or XML source nodes, there seems to be some VS code extensions available for that.)
Totally agree - for import mapping xPath/Jsonpath to flatEHR works well - not sure if the reverse is true? e.g can you populate a FHIR bundle via FHIR Path or JSONPath - does
I also agree re Excel, even in this one-off migration , there was inevitably change, as we adjusted the templates and corrected some misunderstanding of the source data/mappings, so the ability to re-create the new flatEHR target (and show diffs/ breaking change) is really important.
