Re: openEHR on FHIR and vice versa

2018-12-19 Thread Tony Shannon 
FYI See example JSON based //openEHR <--> FHIR mapping template //for
Allergy content attached and more here
https://github.com/RippleOSI/Ripple-FHIR/tree/master/FHIR-Ripple_Mapping/examples/templates

This approach has also been designed with npm in mind for easy distribution
and usage, as per video here
https://www.youtube.com/watch?v=iaGGGgJdWvM=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv=9

regards

Tony


On Wed, 19 Dec 2018 at 02:05, Pablo Pazos  wrote:

> 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 
>> 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  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  - 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 
>>> wrote:
>>>
>>>> I also did some mapping work FHIR -> openEHR using Mirth, but this is
>>>> ad-

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Pablo Pazos 
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 
> Sent: Wednesday, December 19, 2018 3:36 am
> Subject: Re: openEHR on FHIR and vice versa
> To: For openEHR technical discussions  >
>
>
> 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  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  - 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 
>> 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
>>

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Diego Boscá 
Transformation programs generated with LinkEHR are pure XQuery, and you are
the one who decides the license of that output program. So nothing stops
you in that regard. XQuery can output json too btw

Regards

El mar., 18 dic. 2018 a las 23:04, Heath Frankel (<
heath.fran...@oceanhealthsystems.com>) escribió:

> 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 
> Sent: Wednesday, December 19, 2018 3:36 am
> Subject: Re: openEHR on FHIR and vice versa
> To: For openEHR technical discussions  >
>
>
> 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  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  - 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 
>> 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
>>

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Heath Frankel 
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 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.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 
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=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=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 
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 
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á 
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 rece

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Heath Frankel 
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.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 
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=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=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 
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 
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á 
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 
(mailto:georg.fe...@uni-wuerzburg.de>>) escribió:
Hello,
I have just read the paper "Combining Archetypes with Fas

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Pablo Pazos 
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 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 :(
>
> this will not generally work. There is no logic to what is in FHIR
> resources. For example, there is no openEHR class matching the FHIR
> resource 'MedicationAdministration'. The latter has attributes mostly
> matching various Medication archetypes, but is more like a template than an
> archetype. But it also has some attributes matching openEHR context (RM)
> attributes, e.g. subject, context, performer etc. And some things that
> really just should not be there, like eventHistory. And things unlikely to
> work, e.g. 'instantiates'. And some strange things like the pair reasonCode
> (reason why administration performed) and statusReason (reason why the
> administration was not performed).
>
I'm not implying each FHIR resource has a correspondent openEHR class or
vice-versa. To be correct, I should add "create the mappings that can be
done at the IM level", other mappings, might be done between a FHIR
resource and an openEHR archetype or archetypes (like
MedicationAdministration), and others might be done between a FHIR profile
and an openEHR archetype/s. The point was: without this, the
transformations are 100% manual, with this, the transformations can be
assisted at some point, but this is far from automatic transformations.



> But then go have a look at FHIR Observation, and you see it is much more
> generic, but very inflexible. To find e.g. Blood Pressure (measurement) you
> have to find a profile, like this one on simplifier.net
> . This gets rid of the main
> valueQuantity and then packs in the required BP structure (or at least a
> bit of it) as a free-tree 'component' at the bottom.
>
> I have been unable to ascertain any scientific or formal principles on
> which FHIR modelling is based, which is something you need in order to
> write a model converter (unless your converter just has new code for every
> single model).
>
> I don't claim that openEHR RM or archetypes are perfect by any means, but
> they have many underpinning principles which are generally followed, and
> that enables one to write the openEHR side of any converter based on those
> principle, with exceptional handling for places where we made a mistake or
> there is an anomaly.
>
> - thomas
>
>
> ___
> 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://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

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Thomas Beale 


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 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 :(


this will not generally work. There is no logic to what is in FHIR 
resources. For example, there is no openEHR class matching the FHIR 
resource 'MedicationAdministration'. The latter has attributes mostly 
matching various Medication archetypes, but is more like a template than 
an archetype. But it also has some attributes matching openEHR context 
(RM) attributes, e.g. subject, context, performer etc. And some things 
that really just should not be there, like eventHistory. And things 
unlikely to work, e.g. 'instantiates'. And some strange things like the 
pair reasonCode (reason why administration performed) and statusReason 
(reason why the administration was not performed).


But then go have a look at FHIR Observation, and you see it is much more 
generic, but very inflexible. To find e.g. Blood Pressure (measurement) 
you have to find a profile, like this one on simplifier.net 
. This gets rid of the main 
valueQuantity and then packs in the required BP structure (or at least a 
bit of it) as a free-tree 'component' at the bottom.


I have been unable to ascertain any scientific or formal principles on 
which FHIR modelling is based, which is something you need in order to 
write a model converter (unless your converter just has new code for 
every single model).


I don't claim that openEHR RM or archetypes are perfect by any means, 
but they have many underpinning principles which are generally followed, 
and that enables one to write the openEHR side of any converter based on 
those principle, with exceptional handling for places where we made a 
mistake or there is an anomaly.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Pablo Pazos 
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  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  - 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 
> 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 
>> 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á :
>>>
 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.

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Ian McNicoll 
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
 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  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 
> 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á :
>>
>>> 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ürzburgTel.: +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] 
>>>
>>> [image: Twitter]   [image: LinkedIn]
>>>    [image: Maps]

Re: openEHR on FHIR and vice versa

2018-12-17 Thread Dileep V S 
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 mapped to FHIT
resource nodes and can be contained within the archetypes

regards
Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in


On Tue, Dec 18, 2018 at 4:43 AM Bert Verhees  wrote:

> 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 
>> 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 
>> 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á :
>>>
 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

Re: openEHR on FHIR and vice versa

2018-12-17 Thread Bert Verhees 
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  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 
> 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á :
>>
>>> 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ürzburgTel.: +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:

Re: openEHR on FHIR and vice versa

2018-12-17 Thread Pablo Pazos 
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 
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á :
>
>> 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ürzburgTel.: +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] 
>>
>> [image: Twitter]   [image: LinkedIn]
>>  [image: Maps]
>> 
>>
>> 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

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Georg Fette 

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  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

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Diego Boscá 
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 Import->FHIR
> option this StructureDefinition :
>
>
> {"resourceType":"StructureDefinition","id":"Test","name":"Test","type":"Test","baseDefinition":"
> http://hl7.org/fhir/StructureDefinition/DomainResource
> ","snapshot":{"element":[{"id":"Test","path":"Test","min":0,"max":"*"}]}}
>
> A dialog appeared, in which I could configure some import details. But
> after that nothing happed. Is there an example available, which shows
> what the FHIR import in LinkEHR is capable of ?
> 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  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] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Diego Boscá 
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, bespoke, one.
>
> The choices FHIR made for its Resources differ from those of OpenEHR and
> CIMI archetypes.
> They do NOT share the same Reference Model.
>
> Gerard   Freriks
> +31 620 34 70 88
> ‭+31 182 22 59 46‬
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 14 Dec 2018, at 11:48, Diego Boscá  wrote:
>
> 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ürzburgTel.: +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] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> 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

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Georg Fette 

Hi Diego,
I just tried to import with the LinkEHR studio via the Import->FHIR 
option this StructureDefinition :


{"resourceType":"StructureDefinition","id":"Test","name":"Test","type":"Test","baseDefinition":"http://hl7.org/fhir/StructureDefinition/DomainResource","snapshot":{"element":[{"id":"Test","path":"Test","min":0,"max":"*"}]}}

A dialog appeared, in which I could configure some import details. But 
after that nothing happed. Is there an example available, which shows 
what the FHIR import in LinkEHR is capable of ?

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  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

Re: openEHR on FHIR and vice versa

2018-12-14 Thread GF 
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 Model.

Gerard   Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 14 Dec 2018, at 11:48, Diego Boscá  wrote:
> 
> 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 ( >) 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ürzburgTel.: +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 
> 
> 
> 
> -- 
>  
>       
>   
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es 
> yamp...@gmail.com 
> VeraTech for Health SL 
> +34 654604676 
> 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,

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Jan-Marc Verlinden 
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á :

> 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ürzburgTel.: +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] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> 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
>
>

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Diego Boscá 
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ürzburgTel.: +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] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Tony Shannon 
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 me know if you want any more information on this.
regards
Tony

Dr. Tony Shannon
Director, Ripple Foundation   ripple.foundation
Director, Apperta Foundation apperta.org
tony.shannon@ripple.foundation


On Fri, 14 Dec 2018 at 10:19, Georg Fette 
wrote:

> 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ürzburgTel.: +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
>

On Fri, 14 Dec 2018 at 10:19, Georg Fette 
wrote:

> 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ürzburgTel.: +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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org