Yeah, it is processable, and it isn't based on any specific refrence model so any pair of models should be fine (even non-standard ones)
El mié., 19 dic. 2018 a las 3:05, Pablo Pazos (<pablo.pa...@cabolabs.com>) escribió: > 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 > -- [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
