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.


From: Heath Frankel
Sent: Wednesday, December 19, 2018 8:23:31 AM
To: For openEHR technical discussions
Subject: Re: openEHR on FHIR and vice versa

Thanks Pablo,
I second that.


From: Pablo Pazos <<>>
Sent: Wednesday, December 19, 2018 3:36 am
Subject: Re: openEHR on FHIR and vice versa
To: For openEHR technical discussions 

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.

On Tue, Dec 18, 2018 at 7:58 AM Ian McNicoll 
<<>> wrote:
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

There are various attempts at automation including the Ripple QEWD Jumper work but it will still need quite a lot 
of manual input.


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation<>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On Mon, 17 Dec 2018 at 18:26, Pablo Pazos 
<<>> wrote:
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.

On Fri, Dec 14, 2018 at 8:01 AM Jan-Marc Verlinden 
<<>> wrote:
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.. :-)

Jan-Marc Verlinden<><>

Op vr 14 dec. 2018 om 11:49 schreef Diego Boscá 
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)


El vie., 14 dic. 2018 a las 11:19, Georg Fette 
(<<>>) escribió:
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.

Dipl.-Inf. Georg Fette      Raum: B001
Universität Würzburg        Tel.: +49-(0)931-31-85516
Am Hubland                  Fax.: +49-(0)931-31-86732
97074 Würzburg              mail:<>

openEHR-technical mailing list<>


[VeraTech for Health SL]<>

[Twitter] <>  [LinkedIn]  
<>  [Maps]  


Diego Boscá Tomás / Senior developer<><>

VeraTech for Health SL
+34 654604676<tel:+34%20654604676><>

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada 
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está destinada a 
ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le recordamos que 
sus datos han sido incorporados en el sistema de tratamiento de VERATECH FOR 
HEALTH, SL y que siempre y cuando se cumplan los requisitos exigidos por la 
normativa, usted podrá ejercer sus derechos de acceso, rectificación, 
limitación de tratamiento, supresión, portabilidad y oposición/revocación, en 
los términos que establece la normativa vigente en materia de protección de 
datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011 Valencia o 
bien a través de correo electró<>

Si usted lee este mensaje y no es el destinatario señalado, el empleado o el 
agente responsable de entregar el mensaje al destinatario, o ha recibido esta 
comunicación por error, le informamos que está totalmente prohibida, y puede 
ser ilegal, cualquier divulgación, distribución o reproducción de esta 
comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva 
el mensaje original a la dirección arriba mencionada. Gracias

openEHR-technical mailing list<>
openEHR-technical mailing list<>

Ing. Pablo Pazos Gutiérrez<>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<>   

openEHR-technical mailing list<>
openEHR-technical mailing list<>

Ing. Pablo Pazos Gutiérrez<>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<>   

openEHR-technical mailing list

Reply via email to