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
