Re: inheritance of archetypes

[Bert Verhees]

> c'était une blague...

I see that, sorry for that.

Please understand my situation. I was in the urge to solve a problem in the
ADL1. 4 environment and I was not waiting for someone to tell me that that
problem is already solved because ADL2 will come real soon.

Maybe it is maybe it is not, but that discussion did not help me.

But in the end my problem is solved so everything is oké  now.

Best regards
Bert

Op wo 1 mrt. 2017 15:55 schreef Bert Verhees <bert.verh...@rosa.nl>:

> Lots of good things happening. We will see when major shifts will occur. I
> keep my finger in the wind and expect another year to wait.
>
> I hope sooner. There will be a migration period in which both versions
> will be used.
>
> Bert
>
> Op wo 1 mrt. 2017 15:41 schreef Ian McNicoll <i...@freshehr.com>:
>
> Hi Pieter,
>
> Thanks for the update. This kind of innovation is why I am so keen to make
> the jump to this brave new world.
>
> I'd love to hear more about your main project but will contact you
> separately.
>
> 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 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:
>
> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> 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 ian.mcn

Re: inheritance of archetypes

[Bert Verhees]

Lots of good things happening. We will see when major shifts will occur. I
keep my finger in the wind and expect another year to wait.

I hope sooner. There will be a migration period in which both versions will
be used.

Bert

Op wo 1 mrt. 2017 15:41 schreef Ian McNicoll <i...@freshehr.com>:

> Hi Pieter,
>
> Thanks for the update. This kind of innovation is why I am so keen to make
> the jump to this brave new world.
>
> I'd love to hear more about your main project but will contact you
> separately.
>
> 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 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:
>
> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> 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 ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 10:00, Bert Verhees <bert.verh...@rosa.nl bert.verh...@rosa.nl>> wrote:
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
> Good news Thomas, but don't bring it with disdain.
>
> I don't know what the words means ;)
>
> I got it from google translate, in French it is dedain.
> that appears to be a PR about GDL?
>
> I meant a

Re: inheritance of archetypes

[Ian McNicoll]

Hi Pieter,

Thanks for the update. This kind of innovation is why I am so keen to make
the jump to this brave new world.

I'd love to hear more about your main project but will contact you
separately.

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 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:

> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> 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=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtM
> DJ0bkdUcUQxM2dqSVdrPQ]
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 10:00, Bert Verhees <bert.verh...@rosa.nl ert.verh...@rosa.nl>> wrote:
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
> Good news Thomas, but don't bring it with disdain.
>
> I don't know what the words means ;)
>
> I got it from google translate, in French it is dedain.
> that appears to be a PR about GDL?
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
> So it's not perfect, but it's far from non-existent. I'd say your best bet
> is to use the new version of ADL-designer.
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as 

Re: inheritance of archetypes

[Thomas Beale]

well the problem with continuing to use ADL 1.4 is the in a) weaknesses 
modelling semantics (much weaker in 1.4) b) errors caused by lack of 
differential representation of specialised archetypes (a major problem) 
and c) different representation of templates (in ADL2 they are built-in).


Implementations can standardise on OPT 1.4 without difficulty for some 
time, but this doesn't require continued use of ADL 1.4 for modelling.


- thomas

On 01/03/2017 12:54, Ian McNicoll wrote:

Hi Thomas / Bert,

I think you will find a significant pain point in the modelling 
community. Agree that for now 1.4 .opt is going to be best for 
implementers but as I understand things a 2.0 .opt and related RM 
changes would not be radically different, in any case.


The big difference, and gain (once we get over the line) is much 
easier handling of design-time artefacts, and potential extensibility.



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

Re: inheritance of archetypes

[Pieter Bos]

We’re looking forward to the new ADL-designer. We’re currently building an 
ADL-2 based openEHR implementation and currently doing parts of the archetype 
design by hand until we have better tools.

If you want to use ADL-2 and you’re looking for a java library for your EHR or 
authoring tools, Archie implements ADL-2 and the reference model, plus a lot of 
tools for working with them.
Important for specialization: It include a flattener and operational template 
creator that converts specialized archetypes and templates to an operational 
template. Those make working with specialized archetypes much easier. They 
combine the archetypes, templates, templates overlays and specialized 
archetypes into one flat archetype that you can use in your tools and user 
interfaces.

See http://github.com/nedap/archie . It now also has experimental but usable 
support for rule evaluation.

Licensed under the Apache license, so it should be usable in any kind of 
project you like – open source or proprietary.

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Ian McNicoll <i...@freshehr.com>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Wednesday, 1 March 2017 at 13:20
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: inheritance of archetypes

Hi Bert,

Marand are about to release a major interim update to their ADL-2 Archetype 
tooling. I am told sometime in March).

One of the major design criteria is to be able to create ADL1.4 artefacts and, 
critically, ADL 1.4 .opts so we can use the new tools with existing systems, 
but take advantage of better handling of specialisations etc. @Birger - This 
will also help with transition in tooling like CKM, where we should be able to 
create ADL 1.4 flat forms for review purposes.

We expect this first release to need a bit of work and user-feedback. We 
(freshEHR) have committed to give it a good workout on real-world project so 
that we can rapidly iterate and get it ready for proper release.

This is the year we make the jump, at least in the design space!! I expect 
back-end CDRs and other tooling to be working with ADL1.4 artefacts for some 
time. The impact on CDRs is not actually very significant if we mange the 
transition carefully.

I would be delighted to hear from any developers or companies who might be 
prepared to make a contribution to this project (open-source of course). We 
have had a couple of interesting offers of support already. Good tooling is 
essential to openEHR, and if we get a good set of baseline tools, there are all 
sorts of interesting extensions that could be developed.


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 1 March 2017 at 10:00, Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> wrote:
Op 1-3-2017 om 10:44 schreef Thomas Beale:
Good news Thomas, but don't bring it with disdain.

I don't know what the words means ;)

I got it from google translate, in French it is dedain.
that appears to be a PR about GDL?

I meant a current list of Open Issues, I don't know why the 168 is on top, it 
seems to have the highest priority, I don't understand why.
That is not my discussion point.
So it's not perfect, but it's far from non-existent. I'd say your best bet is 
to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise an 
organization to move to ADL2 as long as it is not stable.
Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. There 
must be many archetype, and many data-storages based on ADL 1.4

And there is another point, companies don't tend to change when they do not 
feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that time, and 
still the computer I work on is configured using IP4, so is my Internet-router.

But the discussion on this technical list can be closed as the point I wanted 
to make is planned to be solved (and maybe soon).

Best regard

Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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

Re: inheritance of archetypes

[Ian McNicoll]

Hi Thomas / Bert,

I think you will find a significant pain point in the modelling community.
Agree that for now 1.4 .opt is going to be best for implementers but as I
understand things a 2.0 .opt and related RM changes would not be radically
different, in any case.

The big difference, and gain (once we get over the line) is much easier
handling of design-time artefacts, and potential extensibility.

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 1 March 2017 at 12:26, Thomas Beale  wrote:

>
>
> On 01/03/2017 10:00, Bert Verhees wrote:
>
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
>
> Good news Thomas, but don't bring it with disdain.
>
>
> I don't know what the words means ;)
>
>
> I got it from google translate, in French it is dedain.
>
>
> c'était une blague...
>
>
> that appears to be a PR about GDL?
>
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
>
>
> ah - probably you wanted to show these issues
> .
> There are issues (always), but not with the specialisation representation.
>
>
> So it's not perfect, but it's far from non-existent. I'd say your best bet
> is to use the new version of ADL-designer.
>
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as long as it is not stable.
>
>
> well, it has a stable release here
> . As noted
> above, there are issues, but there are issues outstanding on everything -
> they get worked on and the results get added to later releases. I'm not
> sure of what the alternative to that is.
>
> Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4.
> There must be many archetype, and many data-storages based on ADL 1.4
>
>
> well CKM is a problem in one sense, but people could work with ADL2 tools
> and save the results as ADL 1.4, which  you can do in the ADL-designer, for
> upload to CKM. That's not ideal, I agree - it would be better if CKM
> upgraded to ADL2.
>
> Data storage is generally based on OPT 1.4, and I think that is also a
> save format of the ADL-designer.
>
>
> And there is another point, companies don't tend to change when they do
> not feel the pain.
> I had my first IP6 course in 1998, I worked for DEC (Digital) at that
> time, and still the computer I work on is configured using IP4, so is my
> Internet-router.
>
>
> well you are pointing out some pain, and I am pointing out the solution.
> If you are not in enough pain, you may not want the solution ;)
>
> - thomas
>
>
> ___
> 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

Re: inheritance of archetypes

[Thomas Beale]

On 01/03/2017 10:00, Bert Verhees wrote:

Op 1-3-2017 om 10:44 schreef Thomas Beale:

Good news Thomas, but don't bring it with disdain.


I don't know what the words means ;)


I got it from google translate, in French it is dedain.


c'était une blague...




that appears to be a PR about GDL?


I meant a current list of Open Issues, I don't know why the 168 is on 
top, it seems to have the highest priority, I don't understand why.

That is not my discussion point.


ah - probably you wanted to show these issues 
. 
There are issues (always), but not with the specialisation representation.




So it's not perfect, but it's far from non-existent. I'd say your 
best bet is to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise 
an organization to move to ADL2 as long as it is not stable.


well, it has a stable release here 
. As noted 
above, there are issues, but there are issues outstanding on everything 
- they get worked on and the results get added to later releases. I'm 
not sure of what the alternative to that is.


Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. 
There must be many archetype, and many data-storages based on ADL 1.4


well CKM is a problem in one sense, but people could work with ADL2 
tools and save the results as ADL 1.4, which  you can do in the 
ADL-designer, for upload to CKM. That's not ideal, I agree - it would be 
better if CKM upgraded to ADL2.


Data storage is generally based on OPT 1.4, and I think that is also a 
save format of the ADL-designer.




And there is another point, companies don't tend to change when they 
do not feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that 
time, and still the computer I work on is configured using IP4, so is 
my Internet-router.


well you are pointing out some pain, and I am pointing out the solution. 
If you are not in enough pain, you may not want the solution ;)


- thomas

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

Re: inheritance of archetypes

[Ian McNicoll]

Hi Bert,

Marand are about to release a major interim update to their ADL-2 Archetype
tooling. I am told sometime in March).

One of the major design criteria is to be able to create ADL1.4 artefacts
and, critically, ADL 1.4 .opts so we can use the new tools with existing
systems, but take advantage of better handling of specialisations etc.
@Birger - This will also help with transition in tooling like CKM, where we
should be able to create ADL 1.4 flat forms for review purposes.

We expect this first release to need a bit of work and user-feedback. We
(freshEHR) have committed to give it a good workout on real-world project
so that we can rapidly iterate and get it ready for proper release.

This is the year we make the jump, at least in the design space!! I expect
back-end CDRs and other tooling to be working with ADL1.4 artefacts for
some time. The impact on CDRs is not actually very significant if we mange
the transition carefully.

I would be delighted to hear from any developers or companies who might be
prepared to make a contribution to this project (open-source of course). We
have had a couple of interesting offers of support already. Good tooling is
essential to openEHR, and if we get a good set of baseline tools, there are
all sorts of interesting extensions that could be developed.


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 1 March 2017 at 10:00, Bert Verhees  wrote:

> Op 1-3-2017 om 10:44 schreef Thomas Beale:
>
>> Good news Thomas, but don't bring it with disdain.
>>>
>>
>> I don't know what the words means ;)
>>
>
> I got it from google translate, in French it is dedain.
>
> that appears to be a PR about GDL?
>>
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
>
> So it's not perfect, but it's far from non-existent. I'd say your best bet
>> is to use the new version of ADL-designer.
>>
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as long as it is not stable.
> Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4.
> There must be many archetype, and many data-storages based on ADL 1.4
>
> And there is another point, companies don't tend to change when they do
> not feel the pain.
> I had my first IP6 course in 1998, I worked for DEC (Digital) at that
> time, and still the computer I work on is configured using IP4, so is my
> Internet-router.
>
> But the discussion on this technical list can be closed as the point I
> wanted to make is planned to be solved (and maybe soon).
>
> Best regard
>
> Bert
>
>
>
> ___
> 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

Re: inheritance of archetypes

[Bert Verhees]

Op 1-3-2017 om 10:44 schreef Thomas Beale:

Good news Thomas, but don't bring it with disdain.


I don't know what the words means ;)


I got it from google translate, in French it is dedain.


that appears to be a PR about GDL?


I meant a current list of Open Issues, I don't know why the 168 is on 
top, it seems to have the highest priority, I don't understand why.

That is not my discussion point.

So it's not perfect, but it's far from non-existent. I'd say your best 
bet is to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise an 
organization to move to ADL2 as long as it is not stable.
Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. 
There must be many archetype, and many data-storages based on ADL 1.4


And there is another point, companies don't tend to change when they do 
not feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that 
time, and still the computer I work on is configured using IP4, so is my 
Internet-router.


But the discussion on this technical list can be closed as the point I 
wanted to make is planned to be solved (and maybe soon).


Best regard
Bert



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

Re: inheritance of archetypes

[Thomas Beale]

we may be able to re-use ideas from the Intermountain Healthcare 
Activity-Based Design (ABD) project I am working on in the US, which 
includes presentation specification in its archetypes (they are not ADL 
archetypes, but something similar).



On 01/03/2017 09:26, Anastasiou A. wrote:


Imagine combining all of this with GDL 
(http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a 
specialised

version of a similar DSL to describe archetype / template aware GUIs.



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

Re: inheritance of archetypes

[Thomas Beale]

On 01/03/2017 09:35, Bert Verhees wrote:

Good news Thomas, but don't bring it with disdain.


I don't know what the words means ;)



Op 1-3-2017 om 10:15 schreef Thomas Beale:
which when they are read into ADL Workbench, are re-engineered into 
differential form


I think the ADL Workbench is a cryptic piece of software which could 
use some GUI-specialists to redesign it, so it will become 
understandable for non-software-specialists.


well, the point is that the ADL Workbench fully implements the 
differential specialisation semantics you are talking about. Whether it 
has a cryptic UI is apparently a subjective matter ;)





Using this technology is just a case of moving to ADL/AOM2.


I wouldn't call it "just a case", ADL2 is not yet fully defined.
See the open cases in the specifications (128):
https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-168?filter=allopenissues 



that appears to be a PR about GDL?



The tooling is not yet ready, and even when there will be a frozen 
standard, it will take years for institutions to migrate. They want a 
stable version, before shifting their core-information to a new 
information-structure.
It is good news, but don't bring it as it is like a breathe, then you 
disregard the hard work of people working on the technical information 
side of institutions.


Well the tooling that is there now is:

 * ADL Workbench, which will transform any set of ADL 1.4 archetypes to
   ADL2 differential form, and generate error messages for
   specialisations that can't be computed
 * ADL-designer, a modern web-based Archetype Editor and Template
   Designer based on ADL2, for which a new release is imminent (I think
   next month), which also reads ADL 1.4 archetypes.
 * various Java implementations of the ADL 2 spec

So it's not perfect, but it's far from non-existent. I'd say your best 
bet is to use the new version of ADL-designer.


- thomas


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

Re: inheritance of archetypes

[Bert Verhees]

Good news Thomas, but don't bring it with disdain.

Op 1-3-2017 om 10:15 schreef Thomas Beale:
which when they are read into ADL Workbench, are re-engineered into 
differential form


I think the ADL Workbench is a cryptic piece of software which could use 
some GUI-specialists to redesign it, so it will become understandable 
for non-software-specialists.



Using this technology is just a case of moving to ADL/AOM2.


I wouldn't call it "just a case", ADL2 is not yet fully defined.
See the open cases in the specifications (128):
https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-168?filter=allopenissues

The tooling is not yet ready, and even when there will be a frozen 
standard, it will take years for institutions to migrate. They want a 
stable version, before shifting their core-information to a new 
information-structure.
It is good news, but don't bring it as it is like a breathe, then you 
disregard the hard work of people working on the technical information 
side of institutions.


Sorry to be harsh on this, but so was your reply,

Best regards
Bert



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

RE: inheritance of archetypes

[Anastasiou A .]

Imagine combining all of this with GDL 
(http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a specialised
version of a similar DSL to describe archetype / template aware GUIs.



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: 01 March 2017 09:15
To: openehr-technical@lists.openehr.org
Subject: Re: inheritance of archetypes




On 01/03/2017 09:03, Bert Verhees wrote:
Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be discussed 
separately.
I do that because in the other message, I describe a real problem which needs a 
solution, and this message is about thinking about a solution in the 
archetype-framework, which will takes for years to come (if it will come, maybe 
I am wrong in my proposal).
-
When talking about specializing. Specializing an archetype is nothing more then 
copying an archetype and add/change some constraints in them.

Only in older ADL 1.4 tools. In ADL2, specialisation is fully 
defined<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation>
 and implemented in the ADL Workbench, and more recently in the ADL-designer 
project<https://github.com/openEHR/adl-designer>. it works just like an OO 
programming language. There are dozens of examples in the test 
archteypes<https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>,
 and also in the CKM archetypes, which when they are read into ADL Workbench, 
are re-engineered into differential form.

This has been the case for over 5 years, with the implementation in ADL 
Workbench being available for around 4. (You can see the revision 
history<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_amendment_record>
 of the AOM2 spec).

Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the parent-classes are 
read to understand the child class. There is no need to process all the 
sourcecode of the child-classes to adapt the changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. Easier to 
maintain code (and one definitely need a test framework).

Imagine that dreaded generic labtest archetype in the other message, I wrote 
today.
How convenient would maintainability become if specializations where really and 
life-inherited from parent archetypes?

Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and add the 
appropriate terminology binding?

Maybe we could, in case of lab-test, just created the child archetypes only in 
memory and on the fly, needing only a few keywords to describe the changes. We 
could take a look at hibernate for Java (or many other ORM-frameworks).
They do not deliver the classes needed for handling specific databases, they 
offer a framework to create/generate those classes.

One could argue that specializations are not always inherited like classes in 
programming languages. That is true. What I suggest here maybe limited to the 
cases where it is real inheritance.

Best regards
Bert Verhees

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

Re: inheritance of archetypes

[Birger Haarbrandt]

Hi all,

when will this be available in the openEHR CKM?

Cheers,

Birger


Am 01.03.2017 um 10:15 schrieb Thomas Beale:




On 01/03/2017 09:03, Bert Verhees wrote:

Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be 
discussed separately.
I do that because in the other message, I describe a real problem 
which needs a solution, and this message is about thinking about a 
solution in the archetype-framework, which will takes for years to 
come (if it will come, maybe I am wrong in my proposal).

-
When talking about specializing. Specializing an archetype is nothing 
more then copying an archetype and add/change some constraints in them.


Only in older ADL 1.4 tools. In ADL2, specialisation is fully defined 
 
and implemented in the ADL Workbench, and more recently in the 
ADL-designer project . it 
works just like an OO programming language. There are dozens of 
examples in the test archteypes 
, 
and also in the CKM archetypes, which when they are read into ADL 
Workbench, are re-engineered into differential form.


This has been the case for over 5 years, with the implementation in 
ADL Workbench being available for around 4. (You can see the revision 
history 
 
of the AOM2 spec).


Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the 
parent-classes are read to understand the child class. There is no 
need to process all the sourcecode of the child-classes to adapt the 
changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. 
Easier to maintain code (and one definitely need a test framework).


Imagine that dreaded generic labtest archetype in the other message, 
I wrote today.
How convenient would maintainability become if specializations where 
really and life-inherited from parent archetypes?


Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and 
add the appropriate terminology binding?


Maybe we could, in case of lab-test, just created the child 
archetypes only in memory and on the fly, needing only a few keywords 
to describe the changes. We could take a look at hibernate for Java 
(or many other ORM-frameworks).
They do not deliver the classes needed for handling specific 
databases, they offer a framework to create/generate those classes.


One could argue that specializations are not always inherited like 
classes in programming languages. That is true. What I suggest here 
maybe limited to the cases where it is real inheritance.


Best regards
Bert Verhees




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



--
*Birger Haarbrandt, M.Sc.*

Peter L. Reichertz Institut für Medizinische Informatik
Technische Universität Braunschweig und
Medizinische Hochschule Hannover
Carl-Neuberg-Str. 1
30625 Hannover

T +49 (0)531 391-2129
F +49 (0)531 391-9502
birger.haarbra...@plri.de
http://www.plri.de

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

Re: inheritance of archetypes

[Thomas Beale]

On 01/03/2017 09:03, Bert Verhees wrote:

Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be 
discussed separately.
I do that because in the other message, I describe a real problem 
which needs a solution, and this message is about thinking about a 
solution in the archetype-framework, which will takes for years to 
come (if it will come, maybe I am wrong in my proposal).

-
When talking about specializing. Specializing an archetype is nothing 
more then copying an archetype and add/change some constraints in them.


Only in older ADL 1.4 tools. In ADL2, specialisation is fully defined 
 
and implemented in the ADL Workbench, and more recently in the 
ADL-designer project . it works 
just like an OO programming language. There are dozens of examples in 
the test archteypes 
, 
and also in the CKM archetypes, which when they are read into ADL 
Workbench, are re-engineered into differential form.


This has been the case for over 5 years, with the implementation in ADL 
Workbench being available for around 4. (You can see the revision 
history 
 
of the AOM2 spec).


Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the 
parent-classes are read to understand the child class. There is no 
need to process all the sourcecode of the child-classes to adapt the 
changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. 
Easier to maintain code (and one definitely need a test framework).


Imagine that dreaded generic labtest archetype in the other message, I 
wrote today.
How convenient would maintainability become if specializations where 
really and life-inherited from parent archetypes?


Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and 
add the appropriate terminology binding?


Maybe we could, in case of lab-test, just created the child archetypes 
only in memory and on the fly, needing only a few keywords to describe 
the changes. We could take a look at hibernate for Java (or many other 
ORM-frameworks).
They do not deliver the classes needed for handling specific 
databases, they offer a framework to create/generate those classes.


One could argue that specializations are not always inherited like 
classes in programming languages. That is true. What I suggest here 
maybe limited to the cases where it is real inheritance.


Best regards
Bert Verhees


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

inheritance of archetypes

[Bert Verhees]

Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be 
discussed separately.
I do that because in the other message, I describe a real problem which 
needs a solution, and this message is about thinking about a solution in 
the archetype-framework, which will takes for years to come (if it will 
come, maybe I am wrong in my proposal).

-
When talking about specializing. Specializing an archetype is nothing 
more then copying an archetype and add/change some constraints in them.


How different is that in programming languages, where the parent-classes 
are read to understand the child class. There is no need to process all 
the sourcecode of the child-classes to adapt the changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. 
Easier to maintain code (and one definitely need a test framework).


Imagine that dreaded generic labtest archetype in the other message, I 
wrote today.
How convenient would maintainability become if specializations where 
really and life-inherited from parent archetypes?


Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and add 
the appropriate terminology binding?


Maybe we could, in case of lab-test, just created the child archetypes 
only in memory and on the fly, needing only a few keywords to describe 
the changes. We could take a look at hibernate for Java (or many other 
ORM-frameworks).
They do not deliver the classes needed for handling specific databases, 
they offer a framework to create/generate those classes.


One could argue that specializations are not always inherited like 
classes in programming languages. That is true. What I suggest here 
maybe limited to the cases where it is real inheritance.


Best regards
Bert Verhees

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