Thanks Pablo, I second that. Regards
Heath _____________________________ From: Pablo Pazos <pablo.pa...@cabolabs.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto: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<mailto: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<mailto: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<http://www.medrecord.io> www.medsafe.io<http://www.medsafe.io> 0653785650 Op vr 14 dec. 2018 om 11:49 schreef Diego Boscá <yamp...@gmail.com<mailto: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<mailto: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<mailto:georg.fe...@uni-wuerzburg.de> --------------------------------------------------------------------- _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- [VeraTech for Health SL]<https://htmlsig.com/t/000001C268PZ> [Twitter] <https://htmlsig.com/t/000001C47QQH> [LinkedIn] <https://htmlsig.com/t/000001C4DPJG> [Maps] <https://htmlsig.com/t/000001BZTWS7> [https://s3.amazonaws.com/htmlsig-assets/spacer.gif] Diego Boscá Tomás / Senior developer diebo...@veratech.es<mailto:diebo...@veratech.es> yamp...@gmail.com<mailto:yamp...@gmail.com> VeraTech for Health SL +34 654604676<tel:+34%20654604676> www.veratech.es<http://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...@veratech.es<mailto: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<mailto: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<mailto: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<mailto:pablo.pa...@cabolabs.com> +598 99 043 145 skype: cabolabs Subscribe to our newsletter<http://eepurl.com/b_w_tj> [https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc&export=download] <https://cabolabs.com/> http://www.cabolabs.com<http://www.cabolabs.com/> https://cloudehrserver.com<https://cloudehrserver.com/> _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto: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<mailto: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<mailto:pablo.pa...@cabolabs.com> +598 99 043 145 skype: cabolabs Subscribe to our newsletter<http://eepurl.com/b_w_tj> [https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc&export=download] <https://cabolabs.com/> http://www.cabolabs.com<http://www.cabolabs.com/> https://cloudehrserver.com<https://cloudehrserver.com/>
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
