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 El mar., 18 dic. 2018 a las 23:04, Heath Frankel (< [email protected]>) escribió: > 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 <[email protected]> > Sent: Wednesday, December 19, 2018 3:36 am > Subject: Re: openEHR on FHIR and vice versa > To: For openEHR technical discussions <[email protected] > > > > > 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 <[email protected]> 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 <[email protected]> - 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: [email protected] >> twitter: @ianmcnicoll >> >> >> Co-Chair, openEHR Foundation [email protected] >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> On Mon, 17 Dec 2018 at 18:26, Pablo Pazos <[email protected]> >> 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 < >>> [email protected]> 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á <[email protected]>: >>>> >>>>> 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 (< >>>>> [email protected]>) 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: [email protected] >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openEHR-technical mailing list >>>>>> [email protected] >>>>>> >>>>>> 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 >>>>> [email protected] >>>>> [email protected] >>>>> >>>>> 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 >>>>> [email protected] >>>>> >>>>> 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 >>>>> [email protected] >>>>> >>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> >>> -- >>> *Ing. Pablo Pazos Gutiérrez* >>> [email protected] >>> +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 >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > -- > *Ing. Pablo Pazos Gutiérrez* > [email protected] > +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 > [email protected] > > 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 [email protected] [email protected] 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 [email protected] 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 [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
