nk
>> 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:*
> *To:* For openEHR technical discussions
> *Subject:* Re: openEHR on FHIR and vice versa
>
> Thanks Pablo,
> I second that.
>
> Regards
>
> Heath
> _____
> From: Pablo Pazos
> Sent: Wednesday, December 19, 2018 3:36 am
> Subject: Re: openEHR
* For openEHR technical discussions
> *Subject:* Re: openEHR on FHIR and vice versa
>
> Thanks Pablo,
> I second that.
>
> Regards
>
> Heath
> _____
> From: Pablo Pazos
> Sent: Wednesday, December 19, 2018 3:36 am
> Subject: Re: openEHR on
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
Thanks Pablo,
I second that.
Regards
Heath
_
From: Pablo Pazos 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
mailto:openehr-technical@lists.opene
On Tue, Dec 18, 2018 at 2:50 PM Thomas Beale
wrote:
>
> On 18/12/2018 17:04, Pablo Pazos wrote:
>
> 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
On 18/12/2018 17:04, Pablo Pazos wrote:
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
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
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 - we have started to put FHIR bindings
in CKM archetypes but in practice, the FHIR-openEHR mappings will between
local FHIR profiles
I also concur with Bert that if CKM were to develop into what is intended
to be, the FHIR mapping problem can cease to be a major concern for
majority of the use cases.
Could we not look at extending term mapping in OpenEHR to cover this
requirement also? That way nodes in archetypes can be
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
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
Hi Diego,
Thank you. That profile worked.
Greetings
Georg
--
-
Dipl.-Inf. Georg Fette Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg
I think this patient profile works with the version on the website
https://send.firefox.com/download/5a8149637d/#iBDOPKD9ZcMkgBXpLbtXPw
El vie., 14 dic. 2018 a las 12:54, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:
> Hi Diego,
> I just tried to import with the LinkEHR studio via the
I was thinking in a openEHR -> FHIR bundle, similar to what they already do
with CDA
El vie., 14 dic. 2018 a las 12:40, GF () escribió:
> The requiremetns for OpenEHR are NOT the same as those for FHIR or CIMI.
> Therefor a complete generic mapping is impossible.
> Always it will be an ad-hoc,
Hi Diego,
I just tried to import with the LinkEHR studio via the Import->FHIR
option this StructureDefinition :
The requiremetns for OpenEHR are NOT the same as those for FHIR or CIMI.
Therefor a complete generic mapping is impossible.
Always it will be an ad-hoc, bespoke, one.
The choices FHIR made for its Resources differ from those of OpenEHR and CIMI
archetypes.
They do NOT share the same Reference
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
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
Hi Georg
In terms of openEHR to/from FHIR transformation, the (open source) QEWDjs
part of our stack does this work.
See this video explainer here (with related JSON transformation examples in
the links below)
https://www.youtube.com/watch?v=iaGGGgJdWvM=9=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv=0s
Let
20 matches
Mail list logo
