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? :) On Tue, Dec 18, 2018 at 7:04 PM Heath Frankel < heath.fran...@oceanhealthsystems.com> wrote: > 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 > ------------------------------ > *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. > > Regards > > Heath > _____________________________ > From: Pablo Pazos <pablo.pa...@cabolabs.com> > Sent: Wednesday, December 19, 2018 3:36 am > Subject: Re: openEHR on FHIR and vice versa > To: For openEHR technical discussions <openehr-technical@lists.openehr.org > > > > > 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 > -- *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
