RE: Syntax for including archetypes in SLOTs, regardless of version

[Heather Leslie]

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image002.jpg@01D497BE.ED038BC0]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them 

Re: openEHR on FHIR and vice versa

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

Re: openEHR on FHIR and vice versa

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

Re: openEHR on FHIR and vice versa

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

[https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
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 
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
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). 

Re: openEHR on FHIR and vice versa

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

[https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
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 
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
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 Fast Health
Interoperability Resources in Future-proof Health Information Systems",
in which the 

AW: AW: Syntax for including archetypes in SLOTs, regardless of version

[Sebastian Garde]

Von: openEHR-technical  Im Auftrag 
von Thomas Beale
Gesendet: Dienstag, 18. Dezember 2018 18:39
An: openehr-technical@lists.openehr.org
Betreff: Re: AW: Syntax for including archetypes in SLOTs, regardless of version


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that 
not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few.

the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.

[SG] Sure – but if it is were the case that only a partial match is required, 
anything could be added to the left or the right (as long as it makes a valid 
archetype id).

Now that you mention it, I do seem to remember we specified a very long time 
ago that those regexes did have to be full validating ones.

[SG] That’s exactly what I mean, yes, thank you. (And that then ensures that 
the above does not match v10 or v15…)

So that means using something more like

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where the 
trailing '.*' matches anything, and the validator regex ensures it is only 
semver dotted version patterns.

- 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

[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

[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: AW: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

On 18/12/2018 16:48, Sebastian Garde wrote:


Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus 
boils down to my question from before whether it is valid or not to 
just leave the version part out completely.


In my understanding the regex needs to be fully matched which means 
you cannot just leave it out completely – but it is not 100% clear 
from the specs as far as I can see (but see my excerpt from the ADL2 
specs from before).


if you are using the regex to validate ids, then you will need the full 
regex to match any valid id. If the regex is just to filter out ids that 
are validated elsewhere then you can minimise the regex.


If we assume the regex does NOT need to be a full match, then the 
validation errors from CKM below are bogus of course.


But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:


For example, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 would 
then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 
v11 etc. for example)


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] 
means that not only v0, v1, v2 are valid, but also v10, v15, v27 to 
name a few.


the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.


Now that you mention it, I do seem to remember we specified a very long 
time ago that those regexes did have to be full validating ones. So that 
means using something more like


openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where 
the trailing '.*' matches anything, and the validator regex ensures it 
is only semver dotted version patterns.


- 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

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

AW: Syntax for including archetypes in SLOTs, regardless of version

[Sebastian Garde]

Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus boils down to 
my question from before whether it is valid or not to just leave the version 
part out completely.
In my understanding the regex needs to be fully matched which means you cannot 
just leave it out completely – but it is not 100% clear from the specs as far 
as I can see (but see my excerpt from the ADL2 specs from before).

If we assume the regex does NOT need to be a full match, then the validation 
errors from CKM below are bogus of course.
But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:
For example, openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 
would then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 v11 
etc. for example)

The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that 
not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few.

A few archetypes in CKM (demographics mainly I think) have shortened this 
further to omit the openEHR-EHR- prefix. This currently turns up as a 
validation error in CKM as well, but in the partial match interpretation, it 
would be validit can be seen as  brief and elegant or regarded as confusing 
(especially with CLUSTERs from the EHR or DEMOGRAPHIC parts).

Personally, I think it is better to always require a full match here – this is 
more explicit and avoids unintended side-effects like the ones described above.
But most importantly, I think this needs to be clarified so that either that 
regex or one with additional open version regex can be used to describe what 
you want to model: any version is allowed (and a template can then tie this 
down).

Regards,
Sebastian
Von: openEHR-technical  Im Auftrag 
von Bakke, Silje Ljosland
Gesendet: Dienstag, 18. Dezember 2018 15:15
An: For openEHR technical discussions 
Betreff: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image002.jpg@01D496F8.22699E70]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any 

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image001.jpg@01D496E4.7F780930]

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog | The Objective 
Stance
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

For reference, these are the various regexes I use in the ADL workbench 
.



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

Re: Syntax for including archetypes in SLOTs, regardless of version

[Karsten Hilbert]

On Tue, Dec 18, 2018 at 01:17:38PM +0100, Karsten Hilbert wrote:

> > In other words, add a pattern to catch “any single (possibly double) digit 
> > version number” (?).
> 
>   \d{1,2}

Ah, sorry, was misled by *number*.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

Re: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.


is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically 
different archetypes - i.e. they contain some breaking change. So 
whether allowing any major version of an archetype in a slot is a good 
default probably needs to be thought about carefully.


- thomas

On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:


Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY 
archetypes, or ENTRY archetypes within COMPOSITIONs or SECTIONs). At 
the moment this has to be noted explicitly (whether because of tooling 
or the specifications, I don’t know), so that in order to include for 
example all historical versions and specialisations of the Body Mass 
Index archetype in a COMPOSITION or SECTION, I have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we 
ever make a v3 BMI archetype, this will then need to be added. This is 
a hassle when modelling archetypes in the first place, and it’s an 
even worse problem for governing them over time.


Based on the discussion I had with Sebastian, and with the kind help 
of some regex geeks on Twitter (you know who you are ), I propose 
one of the following as the default syntax for including any version 
of a given archetype in a SLOT:


 1. An explicit regex for the version number, for example

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
 2. Leaving out entirely the version part of the expression, for
example openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be /possible/ to include a specific version of 
the archetype, but that this should not be the default behaviour of 
the tools.


I don’t particularly care if one of these two suggestions, or an 
entirely different solution, is adopted, but this issue has to be 
decided and implemented soon.


Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no / Twitter: 
@arketyper_no 



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

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

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

Re: Syntax for including archetypes in SLOTs, regardless of version

[Karsten Hilbert]

On Tue, Dec 18, 2018 at 12:09:56PM +, Bakke, Silje Ljosland wrote:

> In other words, add a pattern to catch “any single (possibly double) digit 
> version number” (?).

\d{1,2}

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

v[0-9][0-9] would also include v00-v09, which we don’t want.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Anastasiou A.
Sent: Tuesday, December 18, 2018 1:04 PM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: Syntax for including archetypes in SLOTs, regardless of version

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: Syntax for including archetypes in SLOTs, regardless of version

[Anastasiou A .]

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
Subject: Syntax for including archetypes in SLOTs, regardless of version

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Re: Better definition of 'system_id' attribute in openEHR sytems

[Heath Frankel]

Hi Thomas,
This is an excellent description and is inline with our implementation.

Regards

Heath

From: 3003270n behalf of
Sent: Monday, November 26, 2018 11:43 pm
To: Openehr-Technical
Subject: Better definition of 'system_id' attribute in openEHR sytems


Following SPECPR-99 andthis 
email 
string
 from 2014, the imminent RM 1.0.4 release will include 
SPECRM-80, which improves the 
documentation about system_id, which is recorded in the EHR and also in 
AUDIT_DETAILS, i.e. on each committed version.

In response to this, I have added the following documentation to the 
Architecture Overview, and will also add further text and hot links to the 
specific locations in the EHR and Common parts of the RM. It would be useful to 
know if this agrees with the understanding of openEHR system implementers and 
users.



6.1. The EHR System

The notion of a logical EHR system is central to the openEHR architecture. In 
openEHR, a system is understood as a distinct logical repository corresponding 
to an organisational entity that islegally responsible for the management and 
governance of the healthcare data contained within. This may be a regional 
health service that serves multiple provider enterprises or a single provider 
enterprise such as a larger hospital. The 'system' is therefore in general 
distinct from specific applications and also from provider organisations, even 
if in some cases it happens to be owned by a single provider. It is also 
distinct from any underlying virtualisation infrastructure or cloud computing 
facility, which may house multiple logical EHR systems in a multi-tenant 
fashion. This is clear by comparing the legal responsibilities of the 
infrastructure provider, which are forgeneric IT service management to a 
procurer, which may be a healthcare data management entity. It is the latter 
that undertakes legal responsibility for the content, on behalf of one or more 
healthcare provider organisations.

The technical criterion for identifying an EHR system is that it is the entity 
that assigns version identifiers within a repository.

6.1.1. System Identity

Within the openEHR architecture, a system_id attribute is recorded both within 
each patient EHR (EHR class), and also within the audit created with each 
commit of data to an EHR (AUDIT_DETAILS class). This identifier identifies the 
logical EHR system as described above, and may be of any form. Common forms 
include the reverse domain name and plain and structured string identifiers. 
The system identifier isnot assumed to be directly processable, but may instead 
be used as a key, for example in a service maintaining location information.
___
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

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