Hello,
I have just read the paper "Combining Archetypes with Fast Health Interoperability Resources in Future-proof Health Information Systems", in which the representation of openEHR archetypes as FHIR profiles is presented. As I am also trying to use this approach and I wonder if there are working and publicly available applications (possibly emerged from the above mentioned research) that use that approach ? I am especially interested in:
- transforming openEHR archetypes into FHIR profiles (StructureDefinitions) and storing them in a FHIR server.
- transforming FHIR profiles into openEHR archetypes and storing them in an openEHR server.
- transforming openEHR archetype instances into FHIR resources (Bundles) and storing them in a FHIR server.
- transforming FHIR resources into openEHR instances and storing them in an openEHR server.
Greetings
Georg
Hi Georg
In terms of openEHR to/from FHIR transformation, the (open source) QEWDjs part of our stack does this work.
See this video explainer here (with related JSON transformation examples in the links below)
https://www.youtube.com/watch?v=iaGGGgJdWvM&index=9&list=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv&t=0s
Let me know if you want any more information on this.
regards
Tony
Dr. Tony Shannon
Director, Ripple Foundation ripple.foundation
Director, Apperta Foundation apperta.org
tony.shannon@ripple.foundation
Hello Georg,
The main result of that paper was supporting FHIR as a reference model to define archetypes (you can do that with no limitations on the currently available tool). There is no openEHR archetype ↔ FHIR profile service yet, although I believe that providing a openEHR → FHIR generical transformation could be feasible.
Most of the results of this work are available as import/export functions in LinkEHR: Importing StructureDefinitions should work for most things (in fact, I have been updating this part recently and will have better support for STU3 in next LinkEHR version we publish). The export feature is in the original DSTU format though, I assume we should go further and generate StructureDefinitions as in STU3. For the transformation of data instances, as I said we use archetypes as way to express FHIR profiles and resources, so transforming between them is no more difficult than transforming between openEHR, CDA, ISO13606, ODM, etc. which you can do with the LinkEHR studio (FYI, the LinkEHR Studio version available on the website allows you to test this mapping/transformation part, the only thing you won’t be able to do is to export the output XQuery transformation)
Regards
We are doing something similar at the moment. but instead of doing this inside the archetype we are considering the use of an external mapping tool like Mirth Connect or OpenHIM. But we are not there yet.. 
The requiremetns for OpenEHR are NOT the same as those for FHIR or CIMI.
Therefor a complete generic mapping is impossible.
Always it will be an ad-hoc, bespoke, one.
The choices FHIR made for its Resources differ from those of OpenEHR and CIMI archetypes.
They do NOT share the same Reference Model.
Gerard Freriks
+31 620 34 70 88
+31 182 22 59 46
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
Hi Diego,
I just tried to import with the LinkEHR studio via the Import->FHIR option this StructureDefinition :
{"resourceType":"StructureDefinition","id":"Test","name":"Test","type":"Test","baseDefinition":"http://hl7.org/fhir/StructureDefinition/DomainResource","snapshot":\{"element":\[\{"id":"Test","path":"Test","min":0,"max":"\*"\}\]}}
A dialog appeared, in which I could configure some import details. But after that nothing happed. Is there an example available, which shows what the FHIR import in LinkEHR is capable of ?
Greetings
Georg
I was thinking in a openEHR → FHIR bundle, similar to what they already do with CDA
I think this patient profile works with the version on the website
https://send.firefox.com/download/5a8149637d/#iBDOPKD9ZcMkgBXpLbtXPw
Hi Diego,
Thank you. That profile worked.
Greetings
Georg
I also did some mapping work FHIR → openEHR using Mirth, but this is ad-hoc, no automatic mapping yet, for that you need to define a lot of constraints to make it work automatically. Maybe some semi-automatic tool come out in the future, assisting architects on doing such mappings, either way some kind of human intervention will be needed to define mapping criteria when there are 1 to * mapping possibilities.
In fact is this a bit of exciting question. On one side, the OpenEhr community has the point of view that OpenEhr is static, CKM rules and is planned to cover the whole information requirement for healthcare. Do not invent your own archetypes, but use the high quality CKM archetypes is an advice I often hear, and for which is good reasoning.
But if that is the case, then there is only need for a one time mapping between the CKM archetypes and FHIR.
So, there is not really a problem.
But on the other hand, if you have the opinion that CKM is something nice but you think that you can do better, or you need something else (for example wellness and sports archetypes), then you need to write your own FHIR mapping.
But again, people only using CKM only need a one time mapping between an archetype and a FHIR resource which can last forever. The waiting is for the moment that CKM will create space to create these mappings.
I wonder, would templates be a good way to arrange this?
I am very interested in opinions about this
Best regards
Bert Verhees
I also concur with Bert that if CKM were to develop into what is intended to be, the FHIR mapping problem can cease to be a major concern for majority of the use cases.
Could we not look at extending term mapping in OpenEHR to cover this requirement also? That way nodes in archetypes can be mapped to FHIT resource nodes and can be contained within the archetypes
regards
I agree Pablo and we have to remember that the number of high-quality, truly interoperable FHIR profiles is going to be very small for a long time.
@Dileep V S - we have started to put FHIR bindings in CKM archetypes but in practice, the FHIR-openEHR mappings will between local FHIR profiles
and local templates - see https://github.com/inidus/openehr-care-connect-adaptor
There are various attempts at automation including the Ripple QEWD Jumper work https://www.youtube.com/watch?v=iaGGGgJdWvM but it will still need quite a lot of manual input.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
Yes, in fact the closest we can get to automatic transformations is just defining the mappings between openEHR classes and the correspondent FHIR resources, and feed that to a system that, for a specific openEHR instance, provides a mapper user with constrained options of FHIR resources to choose from, and vice-versa, given a FHIR resource, provide the options of openEHR classes to map to. Then will end up mapping fields of correspondent types. No magic here for now 
But I believe this process can be more intelligent, if we add extra metadata to the definitions (like SNOMED CT annotations with concept ids and expressions), and we have a lot of instance samples where AI algorithms can run on and detect semantic matches. Still, a human needs to do some manual work, but maybe less with the extra help of metadata+AI.
Thinking of 100% automatic generic transformations between any instance of two different information models is currently just science fiction IMHO :), or for a political correct answer: it is an open problem.
this will not generally work. There is no logic to what is in FHIR resources. For example, there is no openEHR class matching the FHIR resource 'MedicationAdministration'. The latter has attributes mostly matching various Medication archetypes, but is more like a template than an archetype. But it also has some attributes matching openEHR context (RM) attributes, e.g. subject, context, performer etc. And some things that really just should not be there, like eventHistory. And things unlikely to work, e.g. 'instantiates'. And some strange things like the pair reasonCode (reason why administration performed) and statusReason (reason why the administration was not performed).
But then go have a look at FHIR Observation, and you see it is much more generic, but very inflexible. To find e.g. Blood Pressure (measurement) you have to find a profile, like this one on simplifier.net <https://simplifier.net/coreprofilesstu3/bp>\. This gets rid of the main valueQuantity and then packs in the required BP structure (or at least a bit of it) as a free-tree 'component' at the bottom.
I have been unable to ascertain any scientific or formal principles on which FHIR modelling is based, which is something you need in order to write a model converter (unless your converter just has new code for every single model).
I don't claim that openEHR RM or archetypes are perfect by any means, but they have many underpinning principles which are generally followed, and that enables one to write the openEHR side of any converter based on those principle, with exceptional handling for places where we made a mistake or there is an anomaly.
- thomas
Yes, in fact the closest we can get to automatic transformations is just defining the mappings between openEHR classes and the correspondent FHIR resources, and feed that to a system that, for a specific openEHR instance, provides a mapper user with constrained options of FHIR resources to choose from, and vice-versa, given a FHIR resource, provide the options of openEHR classes to map to. Then will end up mapping fields of correspondent types. No magic here for now
this will not generally work. There is no logic to what is in FHIR resources. For example, there is no openEHR class matching the FHIR resource ‘MedicationAdministration’. The latter has attributes mostly matching various Medication archetypes, but is more like a template than an archetype. But it also has some attributes matching openEHR context (RM) attributes, e.g. subject, context, performer etc. And some things that really just should not be there, like eventHistory. And things unlikely to work, e.g. ‘instantiates’. And some strange things like the pair reasonCode (reason why administration performed) and statusReason (reason why the administration was not performed).
I’m not implying each FHIR resource has a correspondent openEHR class or vice-versa. To be correct, I should add “create the mappings that can be done at the IM level”, other mappings, might be done between a FHIR resource and an openEHR archetype or archetypes (like MedicationAdministration), and others might be done between a FHIR profile and an openEHR archetype/s. The point was: without this, the transformations are 100% manual, with this, the transformations can be assisted at some point, but this is far from automatic transformations.
Thanks Pablo,
I second that.
Regards
Heath
Although I will add, and I think someone has already suggested this, at least we only have to do this mapping once for each FHIR resource. So as a openEHR/FHIR community we should aim for a set of templates, as Thomas indicated, a set of FHIR extensions, and a library of mappings and transforms.
Sounds like LinkEHR has some capacity to do the mappings but from a community asset perspective we need a Implementation independent technology for the transform. Back in my day of doing HL7 v2 or CDA mappings, this was done using XSLT. I think someone mentioned a JSON equivalent? I still think XSLT would be a good common denominator although perhaps seen as ancient.
Regards
Heath
Transformation programs generated with LinkEHR are pure XQuery, and you are the one who decides the license of that output program. So nothing stops you in that regard. XQuery can output json too btw
Regards
A library of mappings sounds like a great idea, another type of artifact for the CKM maybe?
I believe the LinkEHR mapper has the ability of constructing such mappings in a processable format that can be shared. Diego?