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 <i...@freshehr.com> 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 <dil...@healthelife.in> - 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: i...@freshehr.com > twitter: @ianmcnicoll > > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > On Mon, 17 Dec 2018 at 18:26, Pablo Pazos <pablo.pa...@cabolabs.com> > 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 <jan-m...@medrecord.io> >> 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 >>> www.medrecord.io >>> www.medsafe.io >>> 0653785650 >>> >>> >>> Op vr 14 dec. 2018 om 11:49 schreef Diego Boscá <yamp...@gmail.com>: >>> >>>> 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 >>>> >>>> El vie., 14 dic. 2018 a las 11:19, Georg Fette (< >>>> georg.fe...@uni-wuerzburg.de>) escribió: >>>> >>>>> 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 >>>>> >>>>> -- >>>>> --------------------------------------------------------------------- >>>>> 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: georg.fe...@uni-wuerzburg.de >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> openEHR-technical@lists.openehr.org >>>>> >>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>> >>>> >>>> >>>> -- >>>> >>>> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> >>>> >>>> [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: >>>> LinkedIn] <https://htmlsig.com/t/000001C4DPJG> [image: Maps] >>>> <https://htmlsig.com/t/000001BZTWS7> >>>> >>>> Diego Boscá Tomás / Senior developer >>>> diebo...@veratech.es >>>> yamp...@gmail.com >>>> >>>> VeraTech for Health SL >>>> +34 654604676 <+34%20654604676> >>>> www.veratech.es >>>> >>>> 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ónico >>>> d...@veratech.es >>>> >>>> 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@lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> >> -- >> *Ing. Pablo Pazos Gutiérrez* >> pablo.pa...@cabolabs.com >> +598 99 043 145 >> skype: cabolabs >> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >> <https://cabolabs.com/> >> http://www.cabolabs.com >> https://cloudehrserver.com >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- *Ing. Pablo Pazos Gutiérrez* pablo.pa...@cabolabs.com +598 99 043 145 skype: cabolabs Subscribe to our newsletter <http://eepurl.com/b_w_tj> <https://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
