In fact is this a bit of exciting question. On one side, the OpenEhr community has the point of view that OpenEhr is static, CKM rules and is planned to cover the whole information requirement for healthcare. Do not invent your own archetypes, but use the high quality CKM archetypes is an advice I often hear, and for which is good reasoning.
But if that is the case, then there is only need for a one time mapping between the CKM archetypes and FHIR. So, there is not really a problem. But on the other hand, if you have the opinion that CKM is something nice but you think that you can do better, or you need something else (for example wellness and sports archetypes), then you need to write your own FHIR mapping. But again, people only using CKM only need a one time mapping between an archetype and a FHIR resource which can last forever. The waiting is for the moment that CKM will create space to create these mappings. I wonder, would templates be a good way to arrange this? I am very interested in opinions about this Best regards Bert Verhees Op ma 17 dec. 2018 19:27 schreef Pablo Pazos <[email protected]: > 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
