Re: difference and relationship between openEHR and EN13606
How many in this community, in the past, were on this mailing-list for their school or university.? For me, I don't care, homework or other work. We are all learning and work in the school of life. See the very interesting discussion he/she initiated. ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: difference and relationship between openEHR and EN13606
On 28-08-15 07:54, Seref Arikan wrote: Sorry, but I have to ask: are you doing a homework? This sounds like an accusation (the Sorry, I have to ask-part). Then I don't understand the point. How many in this community, in the past, were on this mailing-list for their school or university.? For me, I don't care, homework or other work. We are all learning and work in the school of life. ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: difference and relationship between openEHR and EN13606
On 27-08-15 19:54, Thomas Beale wrote: I would suggest that CIMI has been simiplified to the point of not being directly usable as an RM by openEHR or 13606 - most of the needed context information is gone in CIMI, and it doesn't distinguish any kind of 'Entry' or clinical statement. Are you saying, that the context information from the reference model is not used? This was a conscious choice in the CIMI community, designed to get buy-in from a much wider range of stakeholders than openEHR or 13606 deals with. Technically, the CIMI approach is to soft-model nearly everything in 'reference archetypes'. and the archetypes fill in the missing reference model context parts? If so, then this makes the two level modeling approach, of course, much more flexible, a kind of new database approach/technique, usable for virtual anything. Sorry if I misunderstand you. Bert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: difference and relationship between openEHR and EN13606
If no one else is volunteering, I can do it over a month or so. I am really quite busy and under time-pressure at this moment Bert On 28-08-15 13:00, Ian McNicoll wrote: Edwin has been around here for a while. I think the suggestion of creating a wiki page based on this discussion (and updating Erik's StackOverflow page) is worthwhile. It is question that is commonly asked and a single summary would be helpful. Any volunteers? 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 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 28 August 2015 at 07:46, Bert Verhees bert.verh...@rosa.nl mailto:bert.verh...@rosa.nl wrote: How many in this community, in the past, were on this mailing-list for their school or university.? For me, I don't care, homework or other work. We are all learning and work in the school of life. See the very interesting discussion he/she initiated. ___ 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 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: difference and relationship between openEHR and EN13606
Edwin has been around here for a while. I think the suggestion of creating a wiki page based on this discussion (and updating Erik's StackOverflow page) is worthwhile. It is question that is commonly asked and a single summary would be helpful. Any volunteers? 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 28 August 2015 at 07:46, Bert Verhees bert.verh...@rosa.nl wrote: How many in this community, in the past, were on this mailing-list for their school or university.? For me, I don't care, homework or other work. We are all learning and work in the school of life. See the very interesting discussion he/she initiated. ___ 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: Archetype versioning: Skipping v1 and going straight to v2?
I can't see any problem to the approach you propose. 2015-08-28 15:05 GMT+02:00 Bakke, Silje Ljosland silje.ljosland.ba...@nasjonalikt.no: Hi everyone, We’ve bumped into an issue related to versioning of archetypes and implementing non-published versions: Several implementation projects are using archetypes from the http://arketyper.no CKM, many of which are still drafts or under review since the CKM switch to v0 for unpublished archetypes was done only recently, and the publicly available tools all use v1 by default, lots of functionality has already been made using unpublished v1 versions of archetypes, and will be deployed this autumn. Of course, when reviewed, these archetypes may go through drastic changes, and this will be a problem once other projects at a later time try to use archetypes which by then may have been published as v1. One of our proposed solutions is to skip v1 for these archetypes and go straight to v2 when publishing them. Is this practically possible, and will it have any adverse consequences? Kind regards, *Silje Ljosland Bakke* Information Architect, RN Coordinator, National Editorial Board for Archetypes National ICT Norway Tel. +47 40203298 Web: http://arketyper.no / Twitter: @arketyper_no https://twitter.com/arketyper_no ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- David Moner Cano Grupo de Informática Biomédica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Politécnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta Valencia – 46022 (España) ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Archetype versioning: Skipping v1 and going straight to v2?
Hi everyone, We've bumped into an issue related to versioning of archetypes and implementing non-published versions: Several implementation projects are using archetypes from the http://arketyper.no CKM, many of which are still drafts or under review since the CKM switch to v0 for unpublished archetypes was done only recently, and the publicly available tools all use v1 by default, lots of functionality has already been made using unpublished v1 versions of archetypes, and will be deployed this autumn. Of course, when reviewed, these archetypes may go through drastic changes, and this will be a problem once other projects at a later time try to use archetypes which by then may have been published as v1. One of our proposed solutions is to skip v1 for these archetypes and go straight to v2 when publishing them. Is this practically possible, and will it have any adverse consequences? Kind regards, Silje Ljosland Bakke Information Architect, RN Coordinator, National Editorial Board for Archetypes National ICT Norway Tel. +47 40203298 Web: http://arketyper.nohttp://arketyper.no/ / Twitter: @arketyper_nohttps://twitter.com/arketyper_no ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Archetype versioning: Skipping v1 and going straight to v2?
Hi Silje, I would not expect any problems. - thomas On 28/08/2015 23:05, Bakke, Silje Ljosland wrote: Hi everyone, We’ve bumped into an issue related to versioning of archetypes and implementing non-published versions: Several implementation projects are using archetypes from the http://arketyper.no CKM, many of which are still drafts or under review since the CKM switch to v0 for unpublished archetypes was done only recently, and the publicly available tools all use v1 by default, lots of functionality has already been made using unpublished v1 versions of archetypes, and will be deployed this autumn. Of course, when reviewed, these archetypes may go through drastic changes, and this will be a problem once other projects at a later time try to use archetypes which by then may have been published as v1. One of our proposed solutions is to skip v1 for these archetypes and go straight to v2 when publishing them. Is this practically possible, and will it have any adverse consequences? Kind regards, *Silje Ljosland Bakke* ** Information Architect, RN Coordinator, National Editorial Board for Archetypes National ICT Norway ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: difference and relationship between openEHR and EN13606
Hi Bert, On 28/08/2015 16:32, Bert Verhees wrote: On 27-08-15 19:54, Thomas Beale wrote: I would suggest that CIMI has been simiplified to the point of not being directly usable as an RM by openEHR or 13606 - most of the needed context information is gone in CIMI, and it doesn't distinguish any kind of 'Entry' or clinical statement. Are you saying, that the context information from the reference model is not used? the CIMI RM https://github.com/opencimi/rm/blob/master/model/Release-3.0.4/BMM/CIMI-RM-3.0.4-generated-from-UML.bmm#has no context information in it. This was a conscious choice in the CIMI community, designed to get buy-in from a much wider range of stakeholders than openEHR or 13606 deals with. Technically, the CIMI approach is to soft-model nearly everything in 'reference archetypes'. and the archetypes fill in the missing reference model context parts? that's the idea. If so, then this makes the two level modeling approach, of course, much more flexible, a kind of new database approach/technique, usable for virtual anything. it makes it more flexible in one sense, but also harder for implementers - now they cannot know where even basic context like subject, times, locations etc are - all that has to be obtained from archetypes. The 'flexibility' comes with a price... What goes in any particular RM for some particular domain or industry needs to be the result of careful analysis of * the need for being able to build reliable software components that can assume some things * the need for a base model with enough useful primitives that it doesn't force endless repeated modelling of the same basic concepts in archetypes * but sufficient flexibility so that all the variability of the domain, and also localization can be accommodated. It's a balancing act. So far in openEHR, the context and most other structures etc have proven to be good. We'll probably get rid of / simplify the ITEM_TREE stuff in Release 1.1, but I can't imagine getting rid of most of the other semantics. - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: difference and relationship between openEHR and EN13606
I agree it is a balancing act in how far the semantics should be in the RM or in the archetypes. Both ways have their pro and contra. Thanks for explaining it Bert On 28-08-15 19:17, Thomas Beale wrote: Hi Bert, On 28/08/2015 16:32, Bert Verhees wrote: On 27-08-15 19:54, Thomas Beale wrote: I would suggest that CIMI has been simiplified to the point of not being directly usable as an RM by openEHR or 13606 - most of the needed context information is gone in CIMI, and it doesn't distinguish any kind of 'Entry' or clinical statement. Are you saying, that the context information from the reference model is not used? the CIMI RM https://github.com/opencimi/rm/blob/master/model/Release-3.0.4/BMM/CIMI-RM-3.0.4-generated-from-UML.bmm#has no context information in it. This was a conscious choice in the CIMI community, designed to get buy-in from a much wider range of stakeholders than openEHR or 13606 deals with. Technically, the CIMI approach is to soft-model nearly everything in 'reference archetypes'. and the archetypes fill in the missing reference model context parts? that's the idea. If so, then this makes the two level modeling approach, of course, much more flexible, a kind of new database approach/technique, usable for virtual anything. it makes it more flexible in one sense, but also harder for implementers - now they cannot know where even basic context like subject, times, locations etc are - all that has to be obtained from archetypes. The 'flexibility' comes with a price... What goes in any particular RM for some particular domain or industry needs to be the result of careful analysis of * the need for being able to build reliable software components that can assume some things * the need for a base model with enough useful primitives that it doesn't force endless repeated modelling of the same basic concepts in archetypes * but sufficient flexibility so that all the variability of the domain, and also localization can be accommodated. It's a balancing act. So far in openEHR, the context and most other structures etc have proven to be good. We'll probably get rid of / simplify the ITEM_TREE stuff in Release 1.1, but I can't imagine getting rid of most of the other semantics. - 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
