State of the clinical modelling program and international CKM

[Heather Leslie]

Dear colleagues,

Apologies for cross posting - just wanted to ensure that we share these 
insights broadly...

We recently passed the eleven-year anniversary for the first upload to the 
international CKM - the body temperature archetype. As Europe readies itself 
for summer holidays and the clinical review season slows down, it is a good 
time to review the progress of the openEHR clinical modelling program.

Roughly 6 weeks ago I created and downloaded a number of reports from CKM. I've 
spent some time analysing the data and thought I'd share what I learned with 
you.
This exploration was triggered by a tweet from Ewan Davis last December asking:
"How many person hours do you think has gone in to creating the openEHR 
archetypes available via CKM - I think it must be in excess of 100,000 hours 
(40 person years)"

It took a while to gather the data and propose reasonable assumptions so that 
we could make time and effort estimates, but here goes...
CKM stats
(As of July 5 2019):

  1.  Community
 *   Registered users - 2239
 *   Countries represented - 95
  2.  Archetype library
 *   Total archetypes - 785
 *   Active archetypes

   i.  
Published - 93

 ii.  Published 
as v1, needing reassessment - 6

   iii.  In review 
- 31, with at least 7 about to be published

   iv.  Draft - 351

 v.  Initial 
(in incubators) - 110

 *   Proposed archetypes - 10

Behind the scenes
(from CKM reports, May 2019)

  1.  Number of archetypes which have completed or are undergoing a review 
process - 130
  2.  Number of review rounds completed - 295
  3.  Number of archetype reviews completed by all reviewers - 2995
  4.  Number of unique reviewers - 272
  5.  Reviews completed per review round - 10.15
  6.  Average number of reviews per archetype - 23.04
  7.  Average number of reviews per reviewer - 11.01
  8.  On average, approximately 100 unique reviewers log into to CKM 900 times 
per month during the past 12 months.

Time estimates
This is where things become interesting...
Task
Hours
Design time
10,437
Reviewer time (assumes 30 minutes per review)
1,498
Editorial time
2,522
Clinical Knowledge Administrator (CKA)
1,057
Translation
775
Total
16,289

This equates to roughly 8.5 person years.

Obviously, I have made some assumptions about the average time for many 
activities and if we factor in incidental conversations or pondering modelling 
conundrums or cross pollination between CKMs we could reasonably increase the 
estimate to 10 person years. However, try as I could, there was no way I could 
justify bumping them up in order to achieve estimates of 20, much less 40, 
person years. These numbers reflect the work for archetypes that are owned and 
managed in the international CKM. This includes an estimation of work done by 
the reviewers and editors from the Apperta and Norwegian CKMs if their 
archetypes are now residing in the international CKM, or multiple CKMs. It does 
not reflect the work done on reviews from the now retired Australian CKM, 
although estimates of design time have been part of the assumptions.

I interpret Ewan's estimate to reflect his impression that the effort to 
achieve what we have done so far was huge. I too believed that the effort was 
epic, but in my head it was still only in the ballpark of about half of his 
initial estimate. That the actual effort appears to be only 8-10 person years 
totally surprised me. Initially my figures were considerably lower; I did go 
back to the figures and tried to massage them upward because this is obviously 
a rather inexact science, more like an educated guestimate, but this is as far 
as I feel comfortable going.

In addition, Thomas Beale estimates that on average there are 14 clinically 
significant data elements per archetype, according to the ADL Workbench. These 
are the relevant data points that we design, review etc. So 785 active 
archetypes x 14 data points/archetype suggests that we have a library of 
approximately 10,990 data points, none of which are duplicates or overlapping 
in the governed archetypes. And if we agree with my estimate of a total of 
16289 hours, the amount of time per data element is 16289/10990 - only 1.48 
hours each, covering design, review, maintenance, governance.

What conclusions can we draw?

  *   Firstly, modelling 'openEHR style' seems to be quite efficient, 
surprising even those of us who are involved daily and secondly, this unique 
collaborative and crowdsourced approach to standardisation of clinical data is 
working well. On top of that, if you remember that more than 95% of the 
editorial work and reviewer's time has been volunteer, then it this truly

RE: Christmas greetings from the CKM team

[Sam Heard]

Thank you for the great report Heather. It is such a big undertaking and you 
have made a wonderful start.
Cheers, Sam

From: openEHR-clinical  On Behalf 
Of Heather Leslie
Sent: Friday, 21 December 2018 7:25 PM
To: For openEHR clinical discussions 
Cc: For openEHR technical discussions ; 
For openEHR implementation discussions 
Subject: Christmas greetings from the CKM team

Hi everyone,

What a year it has been, and great to be able to reflect back on achievements 
and the gathering momentum.

Silje Ljosland Bakke and myself, as clinical program leads would like to thank 
everyone for their contributions and efforts over the year.

Some stats to provide some insight into the ‘state of the CKM’ and activity 
over the year:

  *   Archetypes
 *   443 archetypes available, distributed over 35 projects; and a further 
102 ungoverned ones evolving in incubators
 *   In projects: 322 are draft; 26 currently undergoing review; 79 are 
published for content
 *   In the past 12 months, 16  archetypes were published; 203 archetypes 
were modified; 66 were created and added to CKM as new models
 *   Archetypes for ECG report and alcohol consumption are just on the 
brink of publication – we can expect them to be published very early in the new 
year.
  *   Templates
 *   85 templates have been submitted, mostly as examples of modelling for 
specific scenarios; 77% are in ungoverned incubators
 *   None have been reviewed to final publication status
  *   Translations
 *   Over the years there have been many archetypes that have been 
translated – we currently have representations in 24 languages, the top five 
(obviously excluding English as the default language of CKM) being:

  *   Portuguese (Brazil) - 119 archetypes translated;
  *   Norwegian Bokmal with 110;
  *   Arabic (Syria) with 78
  *   Spanish (Argentina) 51
  *   Spanish (Spain) 42
Again, a huge amount of work by a very small number of volunteers and largely 
invisible and beneath the surface.

  *   CKM users
 *   As of today, 2106 registered users from 93 countries
 *   Top five countries, by number of registered users: Brasil; UK; USA; 
Australia; Sweden
 *   278 new registrants signed up this year, purely by word of mouth. 
Imagine if we did some marketing!
  *   Reviews:
 *   749 registrants have volunteered to participate in reviews
 *   This years:
*   80 unique reviewers participated this year, 75 completing at least 
1 content review and 5 reviewers participate only in translation reviews
*   23 archetypes completed at least one review round this
*   414 archetype reviews were submitted - 375 content reviews in 39 
review rounds; 34 Swedish translation reviews in 7 review rounds
  *   We have 35 projects; 18 public incubators; 15 private incubators
  *   44 archetypes are available on a ‘view only’ basis as they are ‘owned’ by 
other collaborating CKMs – 29 referenced from the UK Apperta CKM; and 5 from 
the Norway CKM

>From an operations point of view it has been really pleasing to see activity 
>increasing and new users actively engaging in reviews.

Silje and I particularly wish to thank all those who participated as Editors – 
the ongoing effort week by week, herding cats behind the scenes and teasing out 
the patterns that make each archetype implementable is easy to underestimate 
and should not be! And to Sebastian for crafting the CKM itself that powers 
this great collaborative effort.

We thank you all for your participation and encourage those who are not yet 
active to indicate your willingness by adopting archetypes that you’d like to 
participate in for review purposes. We value any and all input. There is no 
‘stupid’ answers as everyone views the content from their own professional 
perspective and unique domain knowledge.

By volunteering your comments we have collectively created an extraordinary 
international resource, with no equal – there is no body of work in the public 
domain that is so broad and deep, and so transparent and freely available. And 
all crowd sourced from volunteer participants. Please pat yourselves on the 
back for an extraordinary effort as a community!!

The year has not been without it’s dramas and disagreements, but I am 
continuously amazed at the respect and collegiality by which people collaborate 
in meetings, on openEHR clinical Slack channels and of course, in the archetype 
reviews. Unfortunately the Slack channels are only available by invite only, so 
if you would like to be included please email me directly - 
heather.les...@atomicainformatics.com<mailto:heather.les...@atomicainformatics.com>
 - and I’ll add you in:

Some big topics have been ‘nailed’ this year – in particular the Medications 
family of archetype, which has constituted a massive amount of work by editors 
and reviewers. Others that have finally been published include the tricksy 
archetypes for: Contraindication; Pulse oximetry; Probl

Christmas greetings from the CKM team

[Heather Leslie]

Hi everyone,

What a year it has been, and great to be able to reflect back on achievements 
and the gathering momentum.

Silje Ljosland Bakke and myself, as clinical program leads would like to thank 
everyone for their contributions and efforts over the year.

Some stats to provide some insight into the 'state of the CKM' and activity 
over the year:

  *   Archetypes
 *   443 archetypes available, distributed over 35 projects; and a further 
102 ungoverned ones evolving in incubators
 *   In projects: 322 are draft; 26 currently undergoing review; 79 are 
published for content
 *   In the past 12 months, 16  archetypes were published; 203 archetypes 
were modified; 66 were created and added to CKM as new models
 *   Archetypes for ECG report and alcohol consumption are just on the 
brink of publication - we can expect them to be published very early in the new 
year.
  *   Templates
 *   85 templates have been submitted, mostly as examples of modelling for 
specific scenarios; 77% are in ungoverned incubators
 *   None have been reviewed to final publication status
  *   Translations
 *   Over the years there have been many archetypes that have been 
translated - we currently have representations in 24 languages, the top five 
(obviously excluding English as the default language of CKM) being:

  *   Portuguese (Brazil) - 119 archetypes translated;
  *   Norwegian Bokmal with 110;
  *   Arabic (Syria) with 78
  *   Spanish (Argentina) 51
  *   Spanish (Spain) 42
Again, a huge amount of work by a very small number of volunteers and largely 
invisible and beneath the surface.

  *   CKM users
 *   As of today, 2106 registered users from 93 countries
 *   Top five countries, by number of registered users: Brasil; UK; USA; 
Australia; Sweden
 *   278 new registrants signed up this year, purely by word of mouth. 
Imagine if we did some marketing!
  *   Reviews:
 *   749 registrants have volunteered to participate in reviews
 *   This years:
*   80 unique reviewers participated this year, 75 completing at least 
1 content review and 5 reviewers participate only in translation reviews
*   23 archetypes completed at least one review round this
*   414 archetype reviews were submitted - 375 content reviews in 39 
review rounds; 34 Swedish translation reviews in 7 review rounds
  *   We have 35 projects; 18 public incubators; 15 private incubators
  *   44 archetypes are available on a 'view only' basis as they are 'owned' by 
other collaborating CKMs - 29 referenced from the UK Apperta CKM; and 5 from 
the Norway CKM

>From an operations point of view it has been really pleasing to see activity 
>increasing and new users actively engaging in reviews.

Silje and I particularly wish to thank all those who participated as Editors - 
the ongoing effort week by week, herding cats behind the scenes and teasing out 
the patterns that make each archetype implementable is easy to underestimate 
and should not be! And to Sebastian for crafting the CKM itself that powers 
this great collaborative effort.

We thank you all for your participation and encourage those who are not yet 
active to indicate your willingness by adopting archetypes that you'd like to 
participate in for review purposes. We value any and all input. There is no 
'stupid' answers as everyone views the content from their own professional 
perspective and unique domain knowledge.

By volunteering your comments we have collectively created an extraordinary 
international resource, with no equal - there is no body of work in the public 
domain that is so broad and deep, and so transparent and freely available. And 
all crowd sourced from volunteer participants. Please pat yourselves on the 
back for an extraordinary effort as a community!!

The year has not been without it's dramas and disagreements, but I am 
continuously amazed at the respect and collegiality by which people collaborate 
in meetings, on openEHR clinical Slack channels and of course, in the archetype 
reviews. Unfortunately the Slack channels are only available by invite only, so 
if you would like to be included please email me directly - 
heather.les...@atomicainformatics.com<mailto:heather.les...@atomicainformatics.com>
 - and I'll add you in:

Some big topics have been 'nailed' this year - in particular the Medications 
family of archetype, which has constituted a massive amount of work by editors 
and reviewers. Others that have finally been published include the tricksy 
archetypes for: Contraindication; Pulse oximetry; Problem/Diagnosis qualifier. 
Others like Hip circumference and Waist circumference were easier, low hanging 
fruit.

Also, undergoing what we hope might be their final review round, is the 
Laboratory test OBSERVATION and related CLUSTERs for haematology, biochem, 
serology etc - as you can imagine, achieving consensus has required a huge 
amount of work and checking with impleme

Re: Clinical Knowledge Manager (CKM) - New Release with new Dashboard

[Pablo Pazos]

Awesome! I'll check it out.

On Mon, Mar 13, 2017 at 10:41 AM, Sebastian Garde <
sebastian.ga...@oceaninformatics.com> wrote:

> Dear all,
>
>
>
> We have just updated the openEHR Clinical Knowledge Manager.
>
>
>
> This CKM release adds a new Dashboard for new or not logged-in users. It
> also completely revamps the current Dashboards for logged-in users, editors
> and clinical knowledge administrators. In addition, we have finetuned many
> details around the review process, statistics, various grid tooltips, the
> UCUM unit validation and the general CKM look & feel.
>
> You can view the detailed RELEASE NOTES here:
> https://openehr.atlassian.net/wiki/display/healthmod/CKM+Release+1.7.0
>
>
>
> Very much hope that you like it, but just in case that you experience any
> problems, please first delete your browser cache.
>
> If the problem persists, contact us via CKM’s Help/Report Bug or
> Help/Suggest New Feature or directly by email to c...@oceaninformatics.com
>
>
>
> Best regards
>
> Sebastian
>
>
>
>
>
> ___
> 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
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Clinical Knowledge Manager (CKM) - New Release with new Dashboard

[Sebastian Garde]

Dear all,

We have just updated the openEHR Clinical Knowledge Manager.

This CKM release adds a new Dashboard for new or not logged-in users. It also 
completely revamps the current Dashboards for logged-in users, editors and 
clinical knowledge administrators. In addition, we have finetuned many details 
around the review process, statistics, various grid tooltips, the UCUM unit 
validation and the general CKM look & feel.
You can view the detailed RELEASE NOTES here: 
https://openehr.atlassian.net/wiki/display/healthmod/CKM+Release+1.7.0

Very much hope that you like it, but just in case that you experience any 
problems, please first delete your browser cache.
If the problem persists, contact us via CKM's Help/Report Bug or Help/Suggest 
New Feature or directly by email to 
c...@oceaninformatics.com<mailto:c...@oceaninformatics.com>

Best regards
Sebastian


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

RE: ADL validity rules on CKM

[pablo pazos]

Hi Thomas,
I think it would be very useful to have a centralized list of validity rules 
with a reference to the source (specs, CKM, other specific tool, good practice, 
local rule, etc.).
As a developer, that would help me to use those rules in software.
And as a clinical modeler I can check those rules while designing an archetype 
or a template (manually or using a tool).
The spec rules should be on specs (doh!) but I think we might need something 
more dynamic that we can use to add / maintain rules from all the current 
sources, like a github repo for rules (can be a page on the openEHR wiki o the 
wiki on a github repo).

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: ADL validity rules on CKM
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Wed, 15 Jun 2016 12:03:13 +0100


  

  
  
Hi Pablo,

only a few rules were specified in ADL/AOM 1.4 - you can see them
  in the ADL1.4 spec - I think you will find the newer
HTML version easier to use. They were not collected in an
  easy to read list, but I think we could do this easily enough by
  constructing an index of the relevant paragraph type, and
  inserting that into the document. I'll see what is possible in
  Asciidoctor.



In ADL2, it is the AOM2
spec that provides the validity rule definitions.



I'm not sure what the total set Sebastian uses is, but I suspect
  it includes some of the AOM2 rules, i.e. those that would have the
  same meaning for ADL1.4 archetypes.

We should improve how these rules are represented in the specs
  potentially, and a minor update to the ADL1.4 spec could be used
  to update the effective rule set for ADL 1.4

- thomas





On 14/06/2016 07:54, pablo pazos wrote:



  
  Thanks for the input Sebastian,




  Are all of those internal to the CKM?
  Is there any plan to document them in some place to have
all the rules together?
  

  
  Maybe there are a lot of internal rules that we don't
know of and would be useful to have them documented. (Maybe
a task for the clinical models program?)
  

  

  



  


___
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: ADL validity rules on CKM

[Thomas Beale]

Hi Pablo,

only a few rules were specified in ADL/AOM 1.4 - you can see them in the 
ADL1.4 spec - I think you will find the newer HTML version 
<http://www.openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html> 
easier to use. They were not collected in an easy to read list, but I 
think we could do this easily enough by constructing an index of the 
relevant paragraph type, and inserting that into the document. I'll see 
what is possible in Asciidoctor.


In ADL2, it is the AOM2 spec 
<http://www.openehr.org/releases/AM/latest/AOM2.html>that provides the 
validity rule definitions.


I'm not sure what the total set Sebastian uses is, but I suspect it 
includes some of the AOM2 rules, i.e. those that would have the same 
meaning for ADL1.4 archetypes.


We should improve how these rules are represented in the specs 
potentially, and a minor update to the ADL1.4 spec could be used to 
update the effective rule set for ADL 1.4


- thomas


On 14/06/2016 07:54, pablo pazos wrote:

Thanks for the input Sebastian,

Are all of those internal to the CKM?
Is there any plan to document them in some place to have all the rules 
together?


Maybe there are a lot of internal rules that we don't know of and 
would be useful to have them documented. (Maybe a task for the 
clinical models program?)




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

RE: ADL validity rules on CKM

[Sebastian Garde]

My personal opinion on this:


·ICARM needs to resolved - either it is ok to constrain any functional 
property or it is not.
If ok, then this info (not error) can be removed completely. If not ok, ICARM 
would be VCARMs as well (as it used to be until the discussion started). ICARM 
/ VCARM are implemented as part of the openEHR Java Archetype Validator.

·VUI: I think this should be an official validation error.  VUI is 
implemented as part of the openEHR Java Archetype Validator (actually I am just 
working on an update for this)

·WLIC: This really only applies to a CKM ecosystem of some sort. Could 
be documented somewhere, sure, but really this is just a CKM warning message.

Regards
Sebastian

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Dienstag, 14. Juni 2016 08:55
To: openeh technical <openehr-technical@lists.openehr.org>
Subject: RE: ADL validity rules on CKM

Thanks for the input Sebastian,

Are all of those internal to the CKM?
Is there any plan to document them in some place to have all the rules together?

Maybe there are a lot of internal rules that we don't know of and would be 
useful to have them documented. (Maybe a task for the clinical models program?)

Thanks!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>

From: 
sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com>
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: RE: ADL validity rules on CKM
Date: Tue, 14 Jun 2016 06:45:42 +
Hi Pablo,

ICARM: This is the "softer" form of VCARM - i.e. it is just a piece of 
information that while there is no corresponding attribute in the model, there 
is a functional property that is commonly constrained. Typical examples are 
offset and is_integral. These are frequently constrained. There was a big 
debate a (longer) while about whether this is correct/good practice or not and 
I don't think this has been 100% resolved. For CKM - as well as the Java 
Archetype Validator - we decided to inform the user, but not report this as a 
VCARM.

VUI: This is the error type to report that a unit in a DV_QUANTITY are not 
valid UCUM units as required by the specs.
I believe that you are right that there is no explicit error type named for 
this in the specs...so while this directly validates the specs, the naming VUI 
(Validation Unit Invalid) is arbitrary at present.

WLIC: This is just an internal CKM warning to indicate that the licence for the 
archetype as specified in the ADL differs from the default licence configured 
in CKM.

Hope this helps, regards
Sebastian

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Dienstag, 14. Juni 2016 05:44
To: openeh technical 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Subject: ADL validity rules on CKM

Hi all,

I'm making a small summary of all the ADL validity rules, taking the ADL 1.4  
(1.0.2) spec as my source: 
http://openehr.org/releases/1.0.2/architecture/am/adl.pdf

On the CKM I opened the Audiogram Result archetype that has some validity 
problems and the rules are: ICARM, VUI and WLIC.

The problem is I can't find where those rules are defined. Are those only 
defined in the CKM or is there an spec of those (maybe a newer one)?

Thanks!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>

___ 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: ADL validity rules on CKM

[pablo pazos]

Thanks for the input Sebastian,
Are all of those internal to the CKM?Is there any plan to document them in some 
place to have all the rules together?
Maybe there are a lot of internal rules that we don't know of and would be 
useful to have them documented. (Maybe a task for the clinical models program?)
Thanks!
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: sebastian.ga...@oceaninformatics.com
To: openehr-technical@lists.openehr.org
Subject: RE: ADL validity rules on CKM
Date: Tue, 14 Jun 2016 06:45:42 +









Hi Pablo,
 
ICARM: This is the “softer” form of VCARM – i.e. it is just a piece of 
information that while there is no corresponding attribute in the model, there 
is a functional property that is commonly constrained.
 Typical examples are offset and is_integral. These are frequently constrained. 
There was a big debate a (longer) while about whether this is correct/good 
practice or not and I don’t think this has been 100% resolved. For CKM – as 
well as the
 Java Archetype Validator - we decided to inform the user, but not report this 
as a VCARM.
 
VUI: This is the error type to report that a unit in a DV_QUANTITY are not 
valid UCUM units as required by the specs.

I believe that you are right that there is no explicit error type named for 
this in the specs…so while this directly validates the specs, the naming VUI 
(Validation Unit Invalid) is arbitrary at
 present. 
 
WLIC: This is just an internal CKM warning to indicate that the licence for the 
archetype as specified in the ADL differs from the default licence configured 
in CKM.
 
Hope this helps, regards
Sebastian
 



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos

Sent: Dienstag, 14. Juni 2016 05:44

To: openeh technical <openehr-technical@lists.openehr.org>

Subject: ADL validity rules on CKM


 

Hi all,

 


I'm making a small summary of all the ADL validity rules, taking the ADL 1.4  
(1.0.2) spec as my source: 
http://openehr.org/releases/1.0.2/architecture/am/adl.pdf


 


On the CKM I opened the Audiogram Result archetype that has some validity 
problems and the rules are: ICARM,
 VUI and WLIC.


 


The problem is I can't find where those rules are defined. Are those only 
defined in the CKM or is there an spec of those (maybe a newer one)?


 


Thanks!



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com







___
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: ADL validity rules on CKM

[Sebastian Garde]

Hi Pablo,

ICARM: This is the "softer" form of VCARM - i.e. it is just a piece of 
information that while there is no corresponding attribute in the model, there 
is a functional property that is commonly constrained. Typical examples are 
offset and is_integral. These are frequently constrained. There was a big 
debate a (longer) while about whether this is correct/good practice or not and 
I don't think this has been 100% resolved. For CKM - as well as the Java 
Archetype Validator - we decided to inform the user, but not report this as a 
VCARM.

VUI: This is the error type to report that a unit in a DV_QUANTITY are not 
valid UCUM units as required by the specs.
I believe that you are right that there is no explicit error type named for 
this in the specs...so while this directly validates the specs, the naming VUI 
(Validation Unit Invalid) is arbitrary at present.

WLIC: This is just an internal CKM warning to indicate that the licence for the 
archetype as specified in the ADL differs from the default licence configured 
in CKM.

Hope this helps, regards
Sebastian

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Dienstag, 14. Juni 2016 05:44
To: openeh technical <openehr-technical@lists.openehr.org>
Subject: ADL validity rules on CKM

Hi all,

I'm making a small summary of all the ADL validity rules, taking the ADL 1.4  
(1.0.2) spec as my source: 
http://openehr.org/releases/1.0.2/architecture/am/adl.pdf

On the CKM I opened the Audiogram Result archetype that has some validity 
problems and the rules are: ICARM, VUI and WLIC.

The problem is I can't find where those rules are defined. Are those only 
defined in the CKM or is there an spec of those (maybe a newer one)?

Thanks!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

CKM feature request - bulk export of archetypes in XML format

[Dmitry Baranov]

Hi, could you please implement such a function?

-- 
Regards, Dmitry

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

Re: CKM feature request - bulk export of archetypes in XML format

[Dmitry Baranov]

Hi Peter, it best suits my needs.

>>  Hi, could you please implement such a function?
> Hi Dmitry,
>
> I’m not sure if this helps, but if you already have a local directory of ADL 
> archetypes then you can run the Ocean Archetype Editor in batch-processing 
> mode from the command line to export them as XML.

-- 
Regards, Dmitry

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

Re: CKM feature request - bulk export of archetypes in XML format

[Peter Gummer]

Dmitry Baranov  wrote:
> 
> Hi, could you please implement such a function?


Hi Dmitry,

I’m not sure if this helps, but if you already have a local directory of ADL 
archetypes then you can run the Ocean Archetype Editor in batch-processing mode 
from the command line to export them as XML.

For example, the following command will export all of the CLUSTER archetypes in 
a directory called “archetypes”, writing them to a directory called “exported":

"C:\Program Files (x86)\Ocean Informatics\Archetype 
Editor\ArchetypeEditor.exe" .\archetypes\openEHR-EHR-CLUSTER.*.adl -exportxml 
.\exported

When you run the Archetype Editor in a batch-processing mode like this, it 
opens multiple ADL or XML archetypes one by one, writing each archetype as ADL 
or XML or both.

The command line options are:
ArchetypeEditor.exe [languagecode] [archetypefiles] [-exportadl] 
[-exportxml] [exportdirectory]

The [archetypefiles] argument allows wildcard patterns (e.g., "knowledge\*adl" 
or "knowledge\*xml”).

Both export flags (i.e., -exportadl and -exportxml) can be specified, so that 
ADL and XML will both be generated.

The [exportdirectory] argument is optional. If it is not specified, then each 
archetype is written out to the same directory as the source archetype file. 
(This means that the source archetype is overwritten, if it is output in the 
same format.)

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

Re: CKM feature request - bulk export of archetypes in XML format

[Sebastian Garde]

Yes, Dmitry,

An xml option for the export wouldn't hurt...shouldn't be too difficult 
to implement.

I'll raise a Jira card for it.
In the meantime, Peter's option is great.

Cheers
Sebastian

On 06.10.2015 09:17, Dmitry Baranov wrote:

Hi Peter, it best suits my needs.


  Hi, could you please implement such a function?

Hi Dmitry,

I’m not sure if this helps, but if you already have a local directory of ADL 
archetypes then you can run the Ocean Archetype Editor in batch-processing mode 
from the command line to export them as XML.


--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics

Skype: gardeseb


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Archetype editor, CKM and v0 v1

[Koray Atalag]

+1

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Friday, 7 August 2015 8:07 p.m.
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

I'm assuming there's no reaction to this because everyone is still enjoying 
their well-earned holidays. :)

But this is a serious issue, which leads to only people in the know being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we'd like to avoid, isn't 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

On a related note; the openehr.org website still advertises Archetype Editor 
v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after 
the v1 - v0 change, the newest builds should be linked from the web site.

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

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it's just saying that there has to be one or 
more digits after the 'v'. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the 'v', followed by anything at 
all. This amounts to the same, since any extra digits qualify as anything at 
all.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll


___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[Ocean Informatics]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[View Thomas Beale's profile on LinkedIn]http://uk.linkedin.com/in/thomasbeale


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

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

Looking at this again, AE currently provides two choices

1. Do not include specialisation, in which case the slot constraint matches
the provided slot archetype name and version exactly.

2. Include specialisation where any specialisation of the provided slot
archetype is allowed (but currently only the same version of the supplied
slot archetype).

I suggest that we leave (1) as -is to allow precise slot-fills to be
defined but loosen (2) to allow any version.

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 23 July 2015 at 01:06, Thomas Beale thomas.be...@oceaninformatics.com
wrote:


 good point. Maybe a slightly more civilised version would be

 \.v[0-9]+(\..*)?

 that forces there to be one or more digits, and if there is anything else,
 it must start with a dot. Somewhat safer perhaps.

 - thomas


 On 22/07/2015 23:34, Peter Gummer wrote:

 Hi Ian,

 The + is redundant here, since it’s just saying that there has to be one
 or more digits after the ‘v’. But the next thing that it says is that you
 can have anything at all after those digits.

 So you might as well omit the +:

 \.v[0-9].*

 This says that there has to be a digit after the ‘v’, followed by anything
 at all. This amounts to the same, since any extra digits qualify as
 “anything at all”.

 Peter


 On 23 Jul 2015, at 01:55, Ian McNicoll  i...@freshehr.com
 i...@freshehr.com wrote:

 Thanks Thomas,

 I will go with

 \.v[0-9]+.*

 which will give us a bit of flexibility and solve Dave's problem (I
 think!).

 unless anyone strongly objects, of course.

 Ian

 Dr Ian McNicoll
 mobile +44 (0)775 209 7859
 office +44 (0)1536 414994
 skype: ianmcnicoll
 email: i...@freshehr.com
 twitter: @ianmcnicoll




 ___
 openEHR-technical mailing 
 listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



 --
 [image: Ocean Informatics] http://www.oceaninformatics.com/
 *Thomas Beale Chief Technology Officer*
 +44 7792 403 613 Specification Program, *open*EHR
 http://www.openehr.org/
 Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/
 Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/
 Health IT blog http://wolandscat.net/category/health-informatics/ [image:
 View Thomas Beale's profile on LinkedIn]
 http://uk.linkedin.com/in/thomasbeale

 ___
 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 editor, CKM and v0 v1

[Peter Gummer]

Hi Silje,

Yes, that’s true, and we’ve been wanting to do new releases for a long time but 
it takes time, which we don’t have. There were some incompatibilities between 
the tools and also with old archetypes and templates. I think these have been 
fixed now, but I’m not sure. Somebody would need to test that the tools to make 
sure that they don’t introduce new problems. If we released them in an unstable 
state, this could cause much bigger problems.

Finding time to work on this is the problem.

Regards,
Peter


On 7 Aug 2015, at 18:07, Bakke, Silje Ljosland 
silje.ljosland.ba...@nasjonalikt.nomailto:silje.ljosland.ba...@nasjonalikt.no
 wrote:

I’m assuming there’s no reaction to this because everyone is still enjoying 
their well-earned holidays. ☺

But this is a serious issue, which leads to only people “in the know” being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we’d like to avoid, isn’t 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

On a related note; the openehr.orghttp://openehr.org website still advertises 
Archetype Editor v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. 
Especially now after the v1 - v0 change, the newest builds should be linked 
from the web site.

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

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it’s just saying that there has to be one or 
more digits after the ‘v’. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the ‘v’, followed by anything at 
all. This amounts to the same, since any extra digits qualify as “anything at 
all”.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll



___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[Ocean Informatics]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[View Thomas Beale's profile on LinkedIn]http://uk.linkedin.com/in/thomasbeale


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.orgmailto: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 editor, CKM and v0 v1

[Bakke, Silje Ljosland]

Thanks for replying Peter! ☺

I’ve personally used newer versions of both tools than what’s currently on the 
website, in fact we haven’t used TD v2.6 since we got our CKM in February 2014, 
since it doesn’t work with Norwegian Bokmål (nb) archetypes. If you need people 
to do testing for a release I’d be very happy to help, and I’m sure lots of 
other people would too. Is there any test documentation available so testers 
can know what to do and where to get the test versions of the tools?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Peter Gummer
Sent: Friday, August 07, 2015 10:55 AM
To: For openEHR technical discussions
Subject: Re: Archetype editor, CKM and v0  v1

Hi Silje,

Yes, that’s true, and we’ve been wanting to do new releases for a long time but 
it takes time, which we don’t have. There were some incompatibilities between 
the tools and also with old archetypes and templates. I think these have been 
fixed now, but I’m not sure. Somebody would need to test that the tools to make 
sure that they don’t introduce new problems. If we released them in an unstable 
state, this could cause much bigger problems.

Finding time to work on this is the problem.

Regards,
Peter


On 7 Aug 2015, at 18:07, Bakke, Silje Ljosland 
silje.ljosland.ba...@nasjonalikt.nomailto:silje.ljosland.ba...@nasjonalikt.no
 wrote:

I’m assuming there’s no reaction to this because everyone is still enjoying 
their well-earned holidays. ☺

But this is a serious issue, which leads to only people “in the know” being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we’d like to avoid, isn’t 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

On a related note; the openehr.orghttp://openehr.org website still advertises 
Archetype Editor v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. 
Especially now after the v1 - v0 change, the newest builds should be linked 
from the web site.

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

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it’s just saying that there has to be one or 
more digits after the ‘v’. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the ‘v’, followed by anything at 
all. This amounts to the same, since any extra digits qualify as “anything at 
all”.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[cid:image001.jpg@01D0D101.27A48410]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[cid:image002.png@01D0D101.27A48410]http://uk.linkedin.com/in/thomasbeale


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.orgmailto: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 editor, CKM and v0 v1

[Bakke, Silje Ljosland]

I'm assuming there's no reaction to this because everyone is still enjoying 
their well-earned holidays. :)

But this is a serious issue, which leads to only people in the know being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we'd like to avoid, isn't 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

On a related note; the openehr.org website still advertises Archetype Editor 
v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after 
the v1 - v0 change, the newest builds should be linked from the web site.

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

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it's just saying that there has to be one or 
more digits after the 'v'. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the 'v', followed by anything at 
all. This amounts to the same, since any extra digits qualify as anything at 
all.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll



___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[cid:image001.jpg@01D0D0F8.DC60C2A0]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[cid:image002.png@01D0D0F8.DC60C2A0]http://uk.linkedin.com/in/thomasbeale


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

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

Hi Peter

I have been using the new versions of the tools in 'live' settings for some
time now. I have not come across any showstopper issues. I think we are
pretty well ready to go.

Ian
On Fri, 7 Aug 2015 at 10:54, Peter Gummer peter.gum...@oceaninformatics.com
wrote:

 Hi Silje,

 Yes, that’s true, and we’ve been wanting to do new releases for a long
 time but it takes time, which we don’t have. There were some
 incompatibilities between the tools and also with old archetypes and
 templates. I think these have been fixed now, but I’m not sure. Somebody
 would need to test that the tools to make sure that they don’t introduce
 new problems. If we released them in an unstable state, this could cause
 much bigger problems.

 Finding time to work on this is the problem.

 Regards,
 Peter


 On 7 Aug 2015, at 18:07, Bakke, Silje Ljosland 
 silje.ljosland.ba...@nasjonalikt.no wrote:

 I’m assuming there’s no reaction to this because everyone is still
 enjoying their well-earned holidays. J



 But this is a serious issue, which leads to only people “in the know”
 being able to download updated tools and create and edit archetypes and
 templates which conform to the newest patterns. Precisely what we’d like to
 avoid, isn’t it?



 Regards,
 *Silje*



 *From:* openEHR-technical [
 mailto:openehr-technical-boun...@lists.openehr.org
 openehr-technical-boun...@lists.openehr.org] *On Behalf O**f *Bakke,
 Silje Ljosland
 *Sent:* Tuesday, August 04, 2015 10:45 AM
 *To:* For openEHR technical discussions
 *Subject:* RE: Archetype editor, CKM and v0  v1



 On a related note; the openehr.org website still advertises Archetype
 Editor v2.2.905 beta from 2013, and Template Designer 2.6.1213.3.
 Especially now after the v1 - v0 change, the newest builds should be
 linked from the web site.



 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



 *From:* openEHR-technical [
 mailto:openehr-technical-boun...@lists.openehr.org
 openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Thomas Beale
 *Sent:* Thursday, July 23, 2015 1:07 AM
 *To:* openehr-technical@lists.openehr.org
 *Subject:* Re: Archetype editor, CKM and v0  v1




 good point. Maybe a slightly more civilised version would be

 \.v[0-9]+(\..*)?

 that forces there to be one or more digits, and if there is anything else,
 it must start with a dot. Somewhat safer perhaps.

 - thomas

 On 22/07/2015 23:34, Peter Gummer wrote:

 Hi Ian,



 The + is redundant here, since it’s just saying that there has to be one
 or more digits after the ‘v’. But the next thing that it says is that you
 can have anything at all after those digits.



 So you might as well omit the +:



 \.v[0-9].*



 This says that there has to be a digit after the ‘v’, followed by anything
 at all. This amounts to the same, since any extra digits qualify as
 “anything at all”.



 Peter





 On 23 Jul 2015, at 01:55, Ian McNicoll i...@freshehr.com wrote:



 Thanks Thomas,



 I will go with



 \.v[0-9]+.*



 which will give us a bit of flexibility and solve Dave's problem (I
 think!).



 unless anyone strongly objects, of course.



 Ian


 Dr Ian McNicoll
 mobile +44 (0)775 209 7859
 office +44 (0)1536 414994
 skype: ianmcnicoll
 email: i...@freshehr.com
 twitter: @ianmcnicoll



 ___

 openEHR-technical mailing list

 openEHR-technical@lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



 --

 [image: Ocean Informatics] http://www.oceaninformatics.com/


 *Thomas Beale Chief Technology Officer*
 +44 7792 403 613

 Specification Program, *open*EHR http://www.openehr.org/
 Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/
 Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/
 Health IT blog http://wolandscat.net/category/health-informatics/

 [image: View Thomas Beale's profile on LinkedIn]
 http://uk.linkedin.com/in/thomasbeale


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

RE: Archetype editor, CKM and v0 v1

[Bakke, Silje Ljosland]

On a related note; the openehr.org website still advertises Archetype Editor 
v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after 
the v1 - v0 change, the newest builds should be linked from the web site.

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

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it's just saying that there has to be one or 
more digits after the 'v'. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the 'v', followed by anything at 
all. This amounts to the same, since any extra digits qualify as anything at 
all.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[cid:image001.jpg@01D0CEA1.BB13ADF0]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[cid:image002.png@01D0CEA1.BB13ADF0]http://uk.linkedin.com/in/thomasbeale


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

RE: CKM for training purposes

[Koray Atalag]

+1 pls

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heather Leslie
Sent: Monday, 20 July 2015 8:14 p.m.
To: For openEHR implementation discussions; For openEHR implementation 
discussions; For openEHR technical discussions
Subject: CKM for training purposes

Hi everyone,

I'm seeking expressions of interest by groups who are interested in 
participating in an instance of CKM for the purposes of training in openEHR 
governance.

It is intended to have the first iteration of the training CKM up and running 
in time for Medinfo, which is only 4 weeks away. Rather ambitious perhaps, and 
this will only be possible if it is viable from the point of view of demand 
from the openEHR community and some commitment to contribute a modest amount 
towards the running/maintenance/adaptation costs for education purposes. Over 
time we could potentially add functionality that will allow lecturers/teachers 
to manage a subdomain per class, which could be cleared and reset at the end of 
each course to provide a clean starting point for the next group etc. I have 
already had some great ideas suggested that would enable lecturers to run 
multiple courses in parallel and identify participation from individual class 
members etc.

Please email me directly on 
heather.les...@oceaninformatics.commailto:heather.les...@oceaninformatics.com 
and we can start more detailed discussions with all interested parties and 
determine if this idea is of interest and potentially viable.

Kind regards

Heather

Dr Heather Leslie
MBBS FRACGP FACHI
Consulting  Lead, Ocean Informaticshttp://www.oceaninformatics.com/
Clinical Programme Lead, openEHR Foundationhttp://www.openehr.org/
Phone -  +61 418 966 670
Skype - heatherleslie
Twitter - @omowizard

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

Re: Archetype editor, CKM and v0 v1

[Thomas Beale]

Technically speaking, if we want to properly match any archetype in a 
slot, we need a regex that will match any level of versioning id. Since 
matched archetypes will eventually all have 3-part versions (but today 
might have only 1-part versions), we need to match thngs like


.v0
.v1
.v0.0.1
.v3.0.2

and so on. So Diego's expression will do that. But Sebastian is correct 
- some of the matched archetypes could be test or research archetypes. 
So you need the remaining bit as well. You could in theory use:


v[0-9]+(\.[0-9]+(\.[0-9]+((-rc|-alpha)(\.[0-9]+)?)?)?)?
but I would say it is overkill (you only use regexes like that when you 
think there could be garbage version ids and you want to catch them and 
reject them). A reasonable balance is probably something like


\.v[0-9]+.*

which forces at least one digit of major version, and allows anything at 
all to come after, which is reasonable if we assume that no tools will 
create completely invalid version ids.


For reference, there are some useful regexes here 
https://github.com/openEHR/adl-tools/blob/master/libraries/openehr/src/am/archetype/archetype_hrid.e.


- thomas

On 22/07/2015 15:26, Sebastian Garde wrote:
My understanding was that minor version and patch version would not be 
part of the normal archetype id, which is what you are looking for here?

Otherwise you'd need to allow -alpha etc here as well?

Sebastian


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

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

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 22 July 2015 at 16:37, Thomas Beale thomas.be...@oceaninformatics.com
wrote:


 Technically speaking, if we want to properly match any archetype in a
 slot, we need a regex that will match any level of versioning id. Since
 matched archetypes will eventually all have 3-part versions (but today
 might have only 1-part versions), we need to match thngs like

 .v0
 .v1
 .v0.0.1
 .v3.0.2

 and so on. So Diego's expression will do that. But Sebastian is correct -
 some of the matched archetypes could be test or research archetypes. So you
 need the remaining bit as well. You could in theory use:

 v[0-9]+(\.[0-9]+(\.[0-9]+((-rc|-alpha)(\.[0-9]+)?)?)?)?
 but I would say it is overkill (you only use regexes like that when you
 think there could be garbage version ids and you want to catch them and
 reject them). A reasonable balance is probably something like

 \.v[0-9]+.*

 which forces at least one digit of major version, and allows anything at
 all to come after, which is reasonable if we assume that no tools will
 create completely invalid version ids.

 For reference, there are some useful regexes here
 https://github.com/openEHR/adl-tools/blob/master/libraries/openehr/src/am/archetype/archetype_hrid.e
 .

 - thomas

 On 22/07/2015 15:26, Sebastian Garde wrote:

 My understanding was that minor version and patch version would not be
 part of the normal archetype id, which is what you are looking for here?
 Otherwise you'd need to allow -alpha etc here as well?

 Sebastian



 ___
 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

Archetype editor, CKM and v0 v1

[Barnet David (HEALTH AND SOCIAL CARE INFORMATION CENTRE)]

Hi All

I'm having a bit of an issue with CKM re-versioning archetypes and slots that 
reference Clusters.

When I create a new archetype in the archetype editor (Version 2.2.905 Beta), 
the archetype is saved as version 1. For example
openEHR-EHR-OBSERVATION. blood_pressure.v1.adl

When I upload the archetype to CKM, the process renames the archetype to 
version 0 - for example openEHR-EHR-OBSERVATION. blood_pressure.v0 (we are 
hosted on  version 1.4.0 of the Clinical Knowledge Manager)

The re-versioning  becomes an issue when I use slots. In the Archetype editor I 
can assign a slot to a Cluster (for example), but this process creates a link 
to a version of the Cluster. If it's a new Cluster, this will be version 1. 
When the Cluster and the archetype are uploaded to the CKM, they are both put 
back to version 0. However, the slot Cluster is looking for version 1 of the 
Cluster, which won't exist on the CKM (so CKM can't make the link between these 
2 objects).

Does anyone have a work-around, or have some advice and guidance, for this 
issue?

Kind Regards

Dave Barnet
Interoperability Lead
Interoperability Specifications
Health  Social Care Information Centre
david.bar...@hscic.gov.ukmailto:david.bar...@hscic.gov.uk
www.hscic.gov.ukhttp://www.hscic.gov.uk




This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere


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

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

That will be the one then.

Thx

Ian
On Wed, 22 Jul 2015 at 14:29, Diego Boscá yamp...@gmail.com wrote:

 Second one allows both the new and the old versioning (e.g. v0.0.5 vs v0)
 El 22/7/2015 15:12, Ian McNicoll i...@freshehr.com escribió:

 Thanks Diego

 What is the difference between the 2 ?

 Ian
 On Wed, 22 Jul 2015 at 13:55, Diego Boscá yamp...@gmail.com wrote:

 Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions
 El 22/7/2015 14:22, Ian McNicoll i...@freshehr.com escribió:

 Hi Dave,

 I recognise the problem which is a result of the transition to a much
 richer and better versioning mechanism.

 The Archetype Editor has been updated to handle the new versioning (on
 the openEHR Github, not released yet ) but we will need to adapt the slot
 fill regex to allow for .v0 archetypes, which are now the default for new,
 uncontrolled archetypes.

 The default regex for slot-fill pattern needs to be changed to allow
 any Version not just V1

 openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

 I am not a regex expert - If someone can guide me on how to change this
 to allow .v*, I can update the AE code.

 We will almost certainly have to edit some legacy archetype ADL as well.

 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 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE
 INFORMATION CENTRE) david.bar...@hscic.gov.uk wrote:

  Hi All



 I’m having a bit of an issue with CKM re-versioning archetypes and
 slots that reference Clusters.



 When I create a new archetype in the archetype editor (Version 2.2.905
 Beta), the archetype is saved as version 1. For example

 “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”



 When I upload the archetype to CKM, the process renames the archetype
 to version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” 
 (we
 are hosted on  version 1.4.0 of the Clinical Knowledge Manager)



 The re-versioning  becomes an issue when I use slots. In the Archetype
 editor I can assign a slot to a Cluster (for example), but this process
 creates a link to a version of the Cluster. If it’s a new Cluster, this
 will be version 1. When the Cluster and the archetype are uploaded to the
 CKM, they are both put back to version 0. However, the slot Cluster is
 looking for version 1 of the Cluster, which won’t exist on the CKM (so CKM
 can’t make the link between these 2 objects).



 Does anyone have a work-around, or have some advice and guidance, for
 this issue?



 Kind Regards



 Dave Barnet
 Interoperability Lead

 Interoperability Specifications

 Health  Social Care Information Centre
 david.bar...@hscic.gov.uk
 www.hscic.gov.uk




 

 This message may contain confidential information. If you are not the
 intended recipient please inform the
 sender that you have received the message in error before deleting it.
 Please do not disclose, copy or distribute information in this e-mail
 or take any action in reliance on its contents:
 to do so is strictly prohibited and may be unlawful.

 Thank you for your co-operation.

 NHSmail is the secure email and directory service available for all
 NHS staff in England and Scotland
 NHSmail is approved for exchanging patient data and other sensitive
 information with NHSmail and GSi recipients
 NHSmail provides an email address for your career in the NHS and can
 be accessed anywhere


 

 ___
 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

 ___
 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

 ___
 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

Re: Archetype editor, CKM and v0 v1

[Diego Boscá]

Second one allows both the new and the old versioning (e.g. v0.0.5 vs v0)
El 22/7/2015 15:12, Ian McNicoll i...@freshehr.com escribió:

 Thanks Diego

 What is the difference between the 2 ?

 Ian
 On Wed, 22 Jul 2015 at 13:55, Diego Boscá yamp...@gmail.com wrote:

 Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions
 El 22/7/2015 14:22, Ian McNicoll i...@freshehr.com escribió:

 Hi Dave,

 I recognise the problem which is a result of the transition to a much
 richer and better versioning mechanism.

 The Archetype Editor has been updated to handle the new versioning (on
 the openEHR Github, not released yet ) but we will need to adapt the slot
 fill regex to allow for .v0 archetypes, which are now the default for new,
 uncontrolled archetypes.

 The default regex for slot-fill pattern needs to be changed to allow any
 Version not just V1

 openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

 I am not a regex expert - If someone can guide me on how to change this
 to allow .v*, I can update the AE code.

 We will almost certainly have to edit some legacy archetype ADL as well.

 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 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE
 INFORMATION CENTRE) david.bar...@hscic.gov.uk wrote:

  Hi All



 I’m having a bit of an issue with CKM re-versioning archetypes and
 slots that reference Clusters.



 When I create a new archetype in the archetype editor (Version 2.2.905
 Beta), the archetype is saved as version 1. For example

 “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”



 When I upload the archetype to CKM, the process renames the archetype
 to version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” (we
 are hosted on  version 1.4.0 of the Clinical Knowledge Manager)



 The re-versioning  becomes an issue when I use slots. In the Archetype
 editor I can assign a slot to a Cluster (for example), but this process
 creates a link to a version of the Cluster. If it’s a new Cluster, this
 will be version 1. When the Cluster and the archetype are uploaded to the
 CKM, they are both put back to version 0. However, the slot Cluster is
 looking for version 1 of the Cluster, which won’t exist on the CKM (so CKM
 can’t make the link between these 2 objects).



 Does anyone have a work-around, or have some advice and guidance, for
 this issue?



 Kind Regards



 Dave Barnet
 Interoperability Lead

 Interoperability Specifications

 Health  Social Care Information Centre
 david.bar...@hscic.gov.uk
 www.hscic.gov.uk




 

 This message may contain confidential information. If you are not the
 intended recipient please inform the
 sender that you have received the message in error before deleting it.
 Please do not disclose, copy or distribute information in this e-mail
 or take any action in reliance on its contents:
 to do so is strictly prohibited and may be unlawful.

 Thank you for your co-operation.

 NHSmail is the secure email and directory service available for all NHS
 staff in England and Scotland
 NHSmail is approved for exchanging patient data and other sensitive
 information with NHSmail and GSi recipients
 NHSmail provides an email address for your career in the NHS and can be
 accessed anywhere


 

 ___
 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

 ___
 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

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

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

Thanks Diego

What is the difference between the 2 ?

Ian
On Wed, 22 Jul 2015 at 13:55, Diego Boscá yamp...@gmail.com wrote:

 Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions
 El 22/7/2015 14:22, Ian McNicoll i...@freshehr.com escribió:

 Hi Dave,

 I recognise the problem which is a result of the transition to a much
 richer and better versioning mechanism.

 The Archetype Editor has been updated to handle the new versioning (on
 the openEHR Github, not released yet ) but we will need to adapt the slot
 fill regex to allow for .v0 archetypes, which are now the default for new,
 uncontrolled archetypes.

 The default regex for slot-fill pattern needs to be changed to allow any
 Version not just V1

 openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

 I am not a regex expert - If someone can guide me on how to change this
 to allow .v*, I can update the AE code.

 We will almost certainly have to edit some legacy archetype ADL as well.

 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 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE
 INFORMATION CENTRE) david.bar...@hscic.gov.uk wrote:

  Hi All



 I’m having a bit of an issue with CKM re-versioning archetypes and slots
 that reference Clusters.



 When I create a new archetype in the archetype editor (Version 2.2.905
 Beta), the archetype is saved as version 1. For example

 “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”



 When I upload the archetype to CKM, the process renames the archetype to
 version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” (we
 are hosted on  version 1.4.0 of the Clinical Knowledge Manager)



 The re-versioning  becomes an issue when I use slots. In the Archetype
 editor I can assign a slot to a Cluster (for example), but this process
 creates a link to a version of the Cluster. If it’s a new Cluster, this
 will be version 1. When the Cluster and the archetype are uploaded to the
 CKM, they are both put back to version 0. However, the slot Cluster is
 looking for version 1 of the Cluster, which won’t exist on the CKM (so CKM
 can’t make the link between these 2 objects).



 Does anyone have a work-around, or have some advice and guidance, for
 this issue?



 Kind Regards



 Dave Barnet
 Interoperability Lead

 Interoperability Specifications

 Health  Social Care Information Centre
 david.bar...@hscic.gov.uk
 www.hscic.gov.uk




 

 This message may contain confidential information. If you are not the
 intended recipient please inform the
 sender that you have received the message in error before deleting it.
 Please do not disclose, copy or distribute information in this e-mail or
 take any action in reliance on its contents:
 to do so is strictly prohibited and may be unlawful.

 Thank you for your co-operation.

 NHSmail is the secure email and directory service available for all NHS
 staff in England and Scotland
 NHSmail is approved for exchanging patient data and other sensitive
 information with NHSmail and GSi recipients
 NHSmail provides an email address for your career in the NHS and can be
 accessed anywhere


 

 ___
 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

 ___
 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 editor, CKM and v0 v1

[Peter Gummer]

Hi Ian,

The + is redundant here, since it’s just saying that there has to be one or 
more digits after the ‘v’. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the ‘v’, followed by anything at 
all. This amounts to the same, since any extra digits qualify as “anything at 
all”.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll

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

Re: Archetype editor, CKM and v0 v1

[Thomas Beale]

good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything 
else, it must start with a dot. Somewhat safer perhaps.


- thomas

On 22/07/2015 23:34, Peter Gummer wrote:

Hi Ian,

The + is redundant here, since it’s just saying that there has to be 
one or more digits after the ‘v’. But the next thing that it says is 
that you can have anything at all after those digits.


So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the ‘v’, followed by 
anything at all. This amounts to the same, since any extra digits 
qualify as “anything at all”.


Peter


On 23 Jul 2015, at 01:55, Ian McNicoll i...@freshehr.com 
mailto:i...@freshehr.com wrote:


Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I 
think!).


unless anyone strongly objects, of course.

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




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



--
Ocean Informatics http://www.oceaninformatics.com/  *Thomas Beale
Chief Technology Officer*
+44 7792 403 613 	Specification Program, /open/EHR 
http://www.openehr.org/

Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/
Health IT blog http://wolandscat.net/category/health-informatics/ 
View Thomas Beale's profile on LinkedIn 
http://uk.linkedin.com/in/thomasbeale



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

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

Good point Sebastian,

I was really thinking towards the future and the same slot constraints
appearing or being redefined in templates where tighter constraints might
be needed.

Is that overkill?

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 22 July 2015 at 15:26, Sebastian Garde 
sebastian.ga...@oceaninformatics.com wrote:

  My understanding was that minor version and patch version would not be
 part of the normal archetype id, which is what you are looking for here?
 Otherwise you'd need to allow -alpha etc here as well?

 Sebastian



 On 22.07.2015 16:00, Ian McNicoll wrote:

 That will be the one then.

 Thx

 Ian
  On Wed, 22 Jul 2015 at 14:29, Diego Boscá  yamp...@gmail.com
 yamp...@gmail.com wrote:

 Second one allows both the new and the old versioning (e.g. v0.0.5 vs v0)
 El 22/7/2015 15:12, Ian McNicoll i...@freshehr.com escribió:

 Thanks Diego

 What is the difference between the 2 ?

 Ian
  On Wed, 22 Jul 2015 at 13:55, Diego Boscá yamp...@gmail.com wrote:

 Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions
 El 22/7/2015 14:22, Ian McNicoll i...@freshehr.com escribió:

 Hi Dave,

  I recognise the problem which is a result of the transition to a
 much richer and better versioning mechanism.

  The Archetype Editor has been updated to handle the new versioning
 (on the openEHR Github, not released yet ) but we will need to adapt the
 slot fill regex to allow for .v0 archetypes, which are now the default for
 new, uncontrolled archetypes.

  The default regex for slot-fill pattern needs to be changed to allow
 any Version not just V1

 openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

 I am not a regex expert - If someone can guide me on how to change
 this to allow .v*, I can update the AE code.

 We will almost certainly have to edit some legacy archetype ADL as
 well.

 Ian









   Dr Ian McNicoll
 mobile +44 (0)775 209 7859 %2B44%20%280%29775%20209%207859
 office +44 (0)1536 414994 %2B44%20%280%291536%20414994


 skype: ianmcnicoll
 email: i...@freshehr.comi...@freshehr.com
 twitter: @ianmcnicoll

Co-Chair, openEHR Foundation
 ian.mcnic...@openehr.orgian.mcnic...@openehr.org
 Director, freshEHR Clinical Informatics Ltd.
 Director, HANDIHealth CIC
 Hon. Senior Research Associate, CHIME, UCL


 On 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE
 INFORMATION CENTRE)  david.bar...@hscic.gov.uk
 david.bar...@hscic.gov.uk wrote:

  Hi All



 I’m having a bit of an issue with CKM re-versioning archetypes and
 slots that reference Clusters.



 When I create a new archetype in the archetype editor (Version
 2.2.905 Beta), the archetype is saved as version 1. For example

 “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”



 When I upload the archetype to CKM, the process renames the archetype
 to version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” 
 (we
 are hosted on  version 1.4.0 of the Clinical Knowledge Manager)



 The re-versioning  becomes an issue when I use slots. In the
 Archetype editor I can assign a slot to a Cluster (for example), but this
 process creates a link to a version of the Cluster. If it’s a new 
 Cluster,
 this will be version 1. When the Cluster and the archetype are uploaded 
 to
 the CKM, they are both put back to version 0. However, the slot Cluster 
 is
 looking for version 1 of the Cluster, which won’t exist on the CKM (so 
 CKM
 can’t make the link between these 2 objects).



 Does anyone have a work-around, or have some advice and guidance, for
 this issue?



 Kind Regards



 Dave Barnet
 Interoperability Lead

 Interoperability Specifications

 Health  Social Care Information Centre
 david.bar...@hscic.gov.uk
 www.hscic.gov.uk




 

 This message may contain confidential information. If you are not the
 intended recipient please inform the
 sender that you have received the message in error before deleting it.
 Please do not disclose, copy or distribute information in this e-mail
 or take any action in reliance on its contents:
 to do so is strictly prohibited and may be unlawful.

 Thank you for your co-operation.

 NHSmail is the secure email and directory service available for all
 NHS staff in England and Scotland
 NHSmail is approved for exchanging patient data and other sensitive
 information with NHSmail and GSi recipients
 NHSmail provides an email address for your career in the NHS and can
 be accessed anywhere


 

 ___
 openEHR-technical

Re: Archetype editor, CKM and v0 v1

[Sebastian Garde]

My understanding was that minor version and patch version would not be 
part of the normal archetype id, which is what you are looking for here?

Otherwise you'd need to allow -alpha etc here as well?

Sebastian



On 22.07.2015 16:00, Ian McNicoll wrote:

That will be the one then.

Thx

Ian
On Wed, 22 Jul 2015 at 14:29, Diego Boscá yamp...@gmail.com 
mailto:yamp...@gmail.com wrote:


Second one allows both the new and the old versioning (e.g. v0.0.5
vs v0)

El 22/7/2015 15:12, Ian McNicoll i...@freshehr.com
mailto:i...@freshehr.com escribió:

Thanks Diego

What is the difference between the 2 ?

Ian
On Wed, 22 Jul 2015 at 13:55, Diego Boscá yamp...@gmail.com
mailto:yamp...@gmail.com wrote:

Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions

El 22/7/2015 14:22, Ian McNicoll i...@freshehr.com
mailto:i...@freshehr.com escribió:

Hi Dave,

I recognise the problem which is a result of the
transition to a much richer and better versioning
mechanism.

The Archetype Editor has been updated to handle the
new versioning (on the openEHR Github, not released
yet ) but we will need to adapt the slot fill regex to
allow for .v0 archetypes, which are now the default
for new, uncontrolled archetypes.

The default regex for slot-fill pattern needs to be
changed to allow any Version not just V1

openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

I am not a regex expert - If someone can guide me on
how to change this to allow .v*, I can update the AE code.

We will almost certainly have to edit some legacy
archetype ADL as well.

Ian









Dr Ian McNicoll
mobile +44 (0)775 209 7859
tel:%2B44%20%280%29775%20209%207859
office +44 (0)1536 414994
tel:%2B44%20%280%291536%20414994


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 22 July 2015 at 12:33, Barnet David (HEALTH AND
SOCIAL CARE INFORMATION CENTRE)
david.bar...@hscic.gov.uk
mailto:david.bar...@hscic.gov.uk wrote:

Hi All

I’m having a bit of an issue with CKM
re-versioning archetypes and slots that reference
Clusters.

When I create a new archetype in the archetype
editor (Version 2.2.905 Beta), the archetype is
saved as version 1. For example

“openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”

When I upload the archetype to CKM, the process
renames the archetype to version 0 – for example
“openEHR-EHR-OBSERVATION. blood_pressure.v0” (we
are hosted on  version 1.4.0 of the Clinical
Knowledge Manager)

The re-versioning  becomes an issue when I use
slots. In the Archetype editor I can assign a slot
to a Cluster (for example), but this process
creates a link to a version of the Cluster. If
it’s a new Cluster, this will be version 1. When
the Cluster and the archetype are uploaded to the
CKM, they are both put back to version 0. However,
the slot Cluster is looking for version 1 of the
Cluster, which won’t exist on the CKM (so CKM
can’t make the link between these 2 objects).

Does anyone have a work-around, or have some
advice and guidance, for this issue?

Kind Regards

Dave Barnet
Interoperability Lead

Interoperability Specifications

Health  Social Care Information Centre
david.bar...@hscic.gov.uk
mailto:david.bar...@hscic.gov.uk
www.hscic.gov.uk http://www.hscic.gov.uk





This message may contain confidential information.
If you are not the intended

Re: Archetype editor, CKM and v0 v1

[Ian McNicoll]

Hi Dave,

I recognise the problem which is a result of the transition to a much
richer and better versioning mechanism.

The Archetype Editor has been updated to handle the new versioning (on the
openEHR Github, not released yet ) but we will need to adapt the slot fill
regex to allow for .v0 archetypes, which are now the default for new,
uncontrolled archetypes.

The default regex for slot-fill pattern needs to be changed to allow any
Version not just V1

openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

I am not a regex expert - If someone can guide me on how to change this to
allow .v*, I can update the AE code.

We will almost certainly have to edit some legacy archetype ADL as well.

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 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE INFORMATION
CENTRE) david.bar...@hscic.gov.uk wrote:

  Hi All



 I’m having a bit of an issue with CKM re-versioning archetypes and slots
 that reference Clusters.



 When I create a new archetype in the archetype editor (Version 2.2.905
 Beta), the archetype is saved as version 1. For example

 “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”



 When I upload the archetype to CKM, the process renames the archetype to
 version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” (we
 are hosted on  version 1.4.0 of the Clinical Knowledge Manager)



 The re-versioning  becomes an issue when I use slots. In the Archetype
 editor I can assign a slot to a Cluster (for example), but this process
 creates a link to a version of the Cluster. If it’s a new Cluster, this
 will be version 1. When the Cluster and the archetype are uploaded to the
 CKM, they are both put back to version 0. However, the slot Cluster is
 looking for version 1 of the Cluster, which won’t exist on the CKM (so CKM
 can’t make the link between these 2 objects).



 Does anyone have a work-around, or have some advice and guidance, for this
 issue?



 Kind Regards



 Dave Barnet
 Interoperability Lead

 Interoperability Specifications

 Health  Social Care Information Centre
 david.bar...@hscic.gov.uk
 www.hscic.gov.uk




 

 This message may contain confidential information. If you are not the
 intended recipient please inform the
 sender that you have received the message in error before deleting it.
 Please do not disclose, copy or distribute information in this e-mail or
 take any action in reliance on its contents:
 to do so is strictly prohibited and may be unlawful.

 Thank you for your co-operation.

 NHSmail is the secure email and directory service available for all NHS
 staff in England and Scotland
 NHSmail is approved for exchanging patient data and other sensitive
 information with NHSmail and GSi recipients
 NHSmail provides an email address for your career in the NHS and can be
 accessed anywhere


 

 ___
 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 editor, CKM and v0 v1

[Diego Boscá]

Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions
El 22/7/2015 14:22, Ian McNicoll i...@freshehr.com escribió:

 Hi Dave,

 I recognise the problem which is a result of the transition to a much
 richer and better versioning mechanism.

 The Archetype Editor has been updated to handle the new versioning (on the
 openEHR Github, not released yet ) but we will need to adapt the slot fill
 regex to allow for .v0 archetypes, which are now the default for new,
 uncontrolled archetypes.

 The default regex for slot-fill pattern needs to be changed to allow any
 Version not just V1

 openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/}

 I am not a regex expert - If someone can guide me on how to change this to
 allow .v*, I can update the AE code.

 We will almost certainly have to edit some legacy archetype ADL as well.

 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 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE INFORMATION
 CENTRE) david.bar...@hscic.gov.uk wrote:

  Hi All



 I’m having a bit of an issue with CKM re-versioning archetypes and slots
 that reference Clusters.



 When I create a new archetype in the archetype editor (Version 2.2.905
 Beta), the archetype is saved as version 1. For example

 “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”



 When I upload the archetype to CKM, the process renames the archetype to
 version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” (we
 are hosted on  version 1.4.0 of the Clinical Knowledge Manager)



 The re-versioning  becomes an issue when I use slots. In the Archetype
 editor I can assign a slot to a Cluster (for example), but this process
 creates a link to a version of the Cluster. If it’s a new Cluster, this
 will be version 1. When the Cluster and the archetype are uploaded to the
 CKM, they are both put back to version 0. However, the slot Cluster is
 looking for version 1 of the Cluster, which won’t exist on the CKM (so CKM
 can’t make the link between these 2 objects).



 Does anyone have a work-around, or have some advice and guidance, for
 this issue?



 Kind Regards



 Dave Barnet
 Interoperability Lead

 Interoperability Specifications

 Health  Social Care Information Centre
 david.bar...@hscic.gov.uk
 www.hscic.gov.uk




 

 This message may contain confidential information. If you are not the
 intended recipient please inform the
 sender that you have received the message in error before deleting it.
 Please do not disclose, copy or distribute information in this e-mail or
 take any action in reliance on its contents:
 to do so is strictly prohibited and may be unlawful.

 Thank you for your co-operation.

 NHSmail is the secure email and directory service available for all NHS
 staff in England and Scotland
 NHSmail is approved for exchanging patient data and other sensitive
 information with NHSmail and GSi recipients
 NHSmail provides an email address for your career in the NHS and can be
 accessed anywhere


 

 ___
 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

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

CKM for training purposes

[Heather Leslie]

Hi everyone,

I'm seeking expressions of interest by groups who are interested in 
participating in an instance of CKM for the purposes of training in openEHR 
governance.

It is intended to have the first iteration of the training CKM up and running 
in time for Medinfo, which is only 4 weeks away. Rather ambitious perhaps, and 
this will only be possible if it is viable from the point of view of demand 
from the openEHR community and some commitment to contribute a modest amount 
towards the running/maintenance/adaptation costs for education purposes. Over 
time we could potentially add functionality that will allow lecturers/teachers 
to manage a subdomain per class, which could be cleared and reset at the end of 
each course to provide a clean starting point for the next group etc. I have 
already had some great ideas suggested that would enable lecturers to run 
multiple courses in parallel and identify participation from individual class 
members etc.

Please email me directly on 
heather.les...@oceaninformatics.commailto:heather.les...@oceaninformatics.com 
and we can start more detailed discussions with all interested parties and 
determine if this idea is of interest and potentially viable.

Kind regards

Heather

Dr Heather Leslie
MBBS FRACGP FACHI
Consulting  Lead, Ocean Informaticshttp://www.oceaninformatics.com/
Clinical Programme Lead, openEHR Foundationhttp://www.openehr.org/
Phone -  +61 418 966 670
Skype - heatherleslie
Twitter - @omowizard

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

Re: CKM error for translator email

[Sebastian Garde]

Hi Pablo,

Looks like a bug to me.

You can submit bug reports for CKM via CKM's help menu
(or directly at 
https://oceanehr.atlassian.net/rest/collectors/1.0/template/form/fa48ed8d?os_authType=none 
)


Regards
Sebastian

On 14.07.2015 09:01, pablo pazos wrote:

Sometimes the translator email field appears empty after being recorded.

Today it happened that after recording the email and starting 
translating some fields, the email appeared empty, then I saw that the 
accreditaion field had the email value.


Now, after saving a partial translation, and starting again with the 
translation, the email is empty again, but a weird thing happened: now 
my email is a field name. See 
http://s13.postimg.org/e5mbrpusn/Clinical_Knowledge_Manager.jpg


Also, I detected on one archetype that I translated, my email wasn't 
there, but I carefully add my email to every archetype I translate.


Any ideas of what's wrong?
Thanks!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com http://cabolabs.com/es/home




---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

CKM error for translator email

[pablo pazos]

Sometimes the translator email field appears empty after being recorded. 
Today it happened that after recording the email and starting translating some 
fields, the email appeared empty, then I saw that the accreditaion field had 
the email value.
Now, after saving a partial translation, and starting again with the 
translation, the email is empty again, but a weird thing happened: now my email 
is a field name. See 
http://s13.postimg.org/e5mbrpusn/Clinical_Knowledge_Manager.jpg
Also, I detected on one archetype that I translated, my email wasn't there, but 
I carefully add my email to every archetype I translate.
Any ideas of what's wrong?Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

How to fix CKM biggest issue

[Heather Leslie]

Hi y?all,

I think there are a couple of conversations happening at different levels.

Ian and Silje have both described the CKM tool being involved in a knowledge 
governance process that is greater than a repository and versioning tool and 
for a specific task. Core functionality involves the complex review process and 
knowledge governance that meets this very specialised need.

ckm

[Bert Verhees]

already running again, stupid networks

CKM new release // Change Requests

[Sebastian Garde]

Hi all,

We have upgraded the Clinical Knowledge Manager at http://openehr.org/ckm

This release adds *Change Requests* to CKM archetypes (and templates, 
termsets and release sets as well).
Any registered user can now create Change Requests...just right-click on 
the resource in the left-hand panel and select Change Requests.

Check out all the details at 
http://www.openehr.org/wiki/display/healthmod/CKM+Change+Requests

The release notes for this release can be found at 
http://www.openehr.org/wiki/display/healthmod/CKM+Release+1.3.0

Regards
Sebastian
-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140414/b2204892/attachment.html

CKM Android Viewer

[Diego Boscá]

Hello all,

We had a student develop an Android based CKM viewer. For the moment we
consider it to be in beta stage, but could be useful. Currently only
Observations are fully processed (and have their structure analyzed). For
the remaining archetype entities only the header is shown. If there is
enough interest then we will work on improving it.

We are working on publishing it into the Google Play store, but you can
install this apk in the meantime (requires to allow the installation from
external sources in some devices).
https://www.dropbox.com/s/t6ixiujjhj0wj5b/RepoViewer.apk

The application is currently in English and Spanish, but could be easily
translated to other languages.

Regards

PS: openEHR CKM won't work until DNS problems are shorted out, so change
the preferences to use one of the other three included repositories (NEHTA,
UK, or EMNAC).
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130810/c12dbf2d/attachment.html

CKM update

[Sebastian Garde]

Dear all,

We have updated the Clinical Knowledge Manager ( 
http://www.openehr.org/ckm ) today.

Among others, this new release adds reviewing for templates based on its 
operational template (OPT).
Some aspects of how archetypes and templates are being displayed and of 
the user interface in general have been improved.
The release also finetunes some aspects of projects, incubators and 
subdomains.

There are many more changes and you can find the detailed list of 
changes here: 
http://www.openehr.org/wiki/display/healthmod/CKM+Release+1.2.2

Best regards,
Sebastian*
*

P.S.:**In case that something looks odd, please empty your browser cache 
and reload CKM.
If the problem persists, please contact me.

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130730/78a313e2/attachment.html

Archetypes on CKM encoding problem (UTF-8 with BOM)

[pablo pazos]

Hi all,

I've downloaded a couple of archetypes from the CKM to start playing around 
with ADL on PHP :)

I've noticed those archetypes contain the BOM (byte order mark), the weird 
characters at the beginning of the ADL.

Shouldn't the ADL files be UTF-8 without BOM?

[0] = ???archetype (adl_version=1.4)
[1] =  openEHR-EHR-OBSERVATION.apgar.v1[0] = ???archetype (adl_version=1.4)
[1] =  openEHR-EHR-OBSERVATION.body_mass_index.v1[0] = ???archetype 
(adl_version=1.4)
[1] =  openEHR-EHR-OBSERVATION.body_weight.v1
For testing purposes I removed the BOM using Notepad++ Encoding change to UTF-8 
Without BOM.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
http://cabolabs.com   
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130523/f6293b49/attachment.html

Void archetype accessing CKM web service (and website?)

[Diego Boscá]

Accessing CKM via web service I have found that the archetype
openEHR-EHR-OBSERVATION.intravascular_pressure-cvp.v1 returns an empty
archetype (0kb size)
http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeInADL?archetypeId=openEHR-EHR-OBSERVATION.intravascular_pressure-cvp.v1

Related archetypes
openEHR-EHR-OBSERVATION.intravascular_pressure-jvp.v1 and
openEHR-EHR-OBSERVATION.intravascular_pressure.v1
http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeInADL?archetypeId=openEHR-EHR-OBSERVATION.intravascular_pressure-jvp.v1
http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeInADL?archetypeId=openEHR-EHR-OBSERVATION.intravascular_pressure.v1

If you visit this archetype on CKM seems ok at first, but for some
reason archetype definition is all grayed out

Void archetype accessing CKM web service (and website?)

[Sebastian Garde]

Hi Diego,

Confirmed as a bug.

There seems to be a problem with an index on the archetype id and for 
some obscure reason doesn't find the archetype -cvp archetype, but finds 
the -jvp one without problems.
If I remove this index, it works ok. While we investigate the underlying 
issue, I have therefore temporarily removed the index, although it 
(slightly) impacts on performance elsewhere.
In any case, you should now be able to access the url ok.

BTW, greyed out parts in the archetype views indicate that the part has 
not been specialised.
There is nothing much in this archetype that has been specialised as far 
as I can tell except for the concept name - this is why everything in 
the definition is greyed out.

Regards
Sebastian

On 13.05.2013 14:04, Diego Bosc? wrote:
 Accessing CKM via web service I have found that the archetype
 openEHR-EHR-OBSERVATION.intravascular_pressure-cvp.v1 returns an empty
 archetype (0kb size)
 http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeInADL?archetypeId=openEHR-EHR-OBSERVATION.intravascular_pressure-cvp.v1

 Related archetypes
 openEHR-EHR-OBSERVATION.intravascular_pressure-jvp.v1 and
 openEHR-EHR-OBSERVATION.intravascular_pressure.v1
 http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeInADL?archetypeId=openEHR-EHR-OBSERVATION.intravascular_pressure-jvp.v1
 http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeInADL?archetypeId=openEHR-EHR-OBSERVATION.intravascular_pressure.v1

 If you visit this archetype on CKM seems ok at first, but for some
 reason archetype definition is all grayed out

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


-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130513/0144a4ba/attachment.html

Regarding new CKM version webservice

[Shinji KOBAYASHI]

I confirmed, the web services working, too.

2013/3/8 Sebastian Garde sebastian.garde at oceaninformatics.com:
 These 4 webservices should work now as expected (using the /ckm url).
 Sebastian


 On 07.03.2013 15:58, Sebastian Garde wrote:

 Hi Shinji,

 I don't think anything has changed there (once it works again).

 Regards
 Sebastian

 On 07.03.2013 14:43, Shinji KOBAYASHI wrote:

 Hi Sebastian,

 Thank you.

 I use getArchetypeIdsFromPartialId API to query archetypes by key word.
 Does web service APIs change?

 Regards,
 Shinji

 2013/3/7 Sebastian Garde sebastian.garde at oceaninformatics.com:

 Hi Shinji,

 No, they are certainly not obsolete.
 This was just a curly bracket that moved one up accidentally.
 I have fixed this locally and will be deploy asap.

 Cheers
 Sebastian


 On 07.03.2013 13:36, Shinji KOBAYASHI wrote:

 These web service APIs are not wroking now. Are they obsoleted?
 getArchetypeIdsFromPartialId
 getArchetypeIdsFromPartialIdWithPositioning
 getAllArchetypeIds
 getAllArchetypeIdsWithPositioning

 I would be very happy, if new APIs are figured.

 Regards,
 Shinji

 2013/3/7 Shinji KOBAYASHI skoba at moss.gr.jp:

 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study
 more.

 Regards,

 2013/3/7 Diego Bosc? yampeku at gmail.com:

 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb


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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb

Regarding new CKM version webservice

[Sebastian Garde]

It should now work with the old URL as well I believe (at least it works 
in the Archetype Editor).

I would still ask everybody to update to the new URL where this is 
possible, because then your request doesn't have to be forwarded from 
one server to the other and back again.
In Archetype Editor: Under Tools/Options set the URL for shared 
repository to http://openehr.org/ckm/services/ArchetypeFinderBean?wsdl

Regards
Sebastian

On 08.03.2013 09:36, Shinji KOBAYASHI wrote:
 I confirmed, the web services working, too.

 2013/3/8 Sebastian Garde sebastian.garde at oceaninformatics.com:
 These 4 webservices should work now as expected (using the /ckm url).
 Sebastian


 On 07.03.2013 15:58, Sebastian Garde wrote:

 Hi Shinji,

 I don't think anything has changed there (once it works again).

 Regards
 Sebastian

 On 07.03.2013 14:43, Shinji KOBAYASHI wrote:

 Hi Sebastian,

 Thank you.

 I use getArchetypeIdsFromPartialId API to query archetypes by key word.
 Does web service APIs change?

 Regards,
 Shinji

 2013/3/7 Sebastian Garde sebastian.garde at oceaninformatics.com:

 Hi Shinji,

 No, they are certainly not obsolete.
 This was just a curly bracket that moved one up accidentally.
 I have fixed this locally and will be deploy asap.

 Cheers
 Sebastian


 On 07.03.2013 13:36, Shinji KOBAYASHI wrote:

 These web service APIs are not wroking now. Are they obsoleted?
 getArchetypeIdsFromPartialId
 getArchetypeIdsFromPartialIdWithPositioning
 getAllArchetypeIds
 getAllArchetypeIdsWithPositioning

 I would be very happy, if new APIs are figured.

 Regards,
 Shinji

 2013/3/7 Shinji KOBAYASHI skoba at moss.gr.jp:

 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study
 more.

 Regards,

 2013/3/7 Diego Bosc? yampeku at gmail.com:

 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb


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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130308/0bb64f64/attachment.html

Regarding new CKM version webservice

[Erik Sundvall]

Hi!

Nice to see the CKM product and the openEHR installation of it being updated!

On Fri, Mar 8, 2013 at 10:00 AM, Sebastian Garde
sebastian.garde at oceaninformatics.com wrote:
 In Archetype Editor: Under Tools/Options set the URL for shared repository
 to http://openehr.org/ckm/services/ArchetypeFinderBean?wsdl

Just a thought:
Some time in a distant future when rethinking/refactoring archetype
handling beyond the CKM product it might be a good idea to exclude
specific company-bound product names (like CKM) and specific
implementation-bound techniques (like Bean) from openEHR
foundation-controlled URIs.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

Regarding new CKM version webservice

[Ian McNicoll]

Hi Diego,

I think this is technical hitch. The intention, AFAIK was to retain
the original endpint, as well as adding the new one.

Ian

On 7 March 2013 10:35, Diego Bosc? yampeku at gmail.com wrote:
 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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



--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation  www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care  www.phcsg.org

Regarding new CKM version webservice

[Diego Boscá]

It gives a 301 code moved permanently
http://en.wikipedia.org/wiki/HTTP_301

2013/3/7 Ian McNicoll Ian.McNicoll at oceaninformatics.com:
 Hi Diego,

 I think this is technical hitch. The intention, AFAIK was to retain
 the original endpint, as well as adding the new one.

 Ian

 On 7 March 2013 10:35, Diego Bosc? yampeku at gmail.com wrote:
 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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



 --
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com

 Clinical Modelling Consultant, Ocean Informatics, UK
 Director openEHR Foundation  www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 SCIMP Working Group, NHS Scotland
 BCS Primary Health Care  www.phcsg.org

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

Regarding new CKM version webservice

[Shinji KOBAYASHI]

Thank you, Diego.

getArchetypeIdsFromPartialId API seems not working here, but I will study more.

Regards,

2013/3/7 Diego Bosc? yampeku at gmail.com:
 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

Regarding new CKM version webservice

[Shinji KOBAYASHI]

These web service APIs are not wroking now. Are they obsoleted?
getArchetypeIdsFromPartialId
getArchetypeIdsFromPartialIdWithPositioning
getAllArchetypeIds
getAllArchetypeIdsWithPositioning

I would be very happy, if new APIs are figured.

Regards,
Shinji

2013/3/7 Shinji KOBAYASHI skoba at moss.gr.jp:
 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study 
 more.

 Regards,

 2013/3/7 Diego Bosc? yampeku at gmail.com:
 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

Regarding new CKM version webservice

[Sebastian Garde]

Hi Shinji,

No, they are certainly not obsolete.
This was just a curly bracket that moved one up accidentally.
I have fixed this locally and will be deploy asap.

Cheers
Sebastian

On 07.03.2013 13:36, Shinji KOBAYASHI wrote:
 These web service APIs are not wroking now. Are they obsoleted?
 getArchetypeIdsFromPartialId
 getArchetypeIdsFromPartialIdWithPositioning
 getAllArchetypeIds
 getAllArchetypeIdsWithPositioning

 I would be very happy, if new APIs are figured.

 Regards,
 Shinji

 2013/3/7 Shinji KOBAYASHI skoba at moss.gr.jp:
 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study 
 more.

 Regards,

 2013/3/7 Diego Bosc? yampeku at gmail.com:
 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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


-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130307/1a7cc4bd/attachment.html

Regarding new CKM version webservice

[Shinji KOBAYASHI]

Hi Sebastian,

Thank you.

I use getArchetypeIdsFromPartialId API to query archetypes by key word.
Does web service APIs change?

Regards,
Shinji

2013/3/7 Sebastian Garde sebastian.garde at oceaninformatics.com:
 Hi Shinji,

 No, they are certainly not obsolete.
 This was just a curly bracket that moved one up accidentally.
 I have fixed this locally and will be deploy asap.

 Cheers
 Sebastian


 On 07.03.2013 13:36, Shinji KOBAYASHI wrote:

 These web service APIs are not wroking now. Are they obsoleted?
 getArchetypeIdsFromPartialId
 getArchetypeIdsFromPartialIdWithPositioning
 getAllArchetypeIds
 getAllArchetypeIdsWithPositioning

 I would be very happy, if new APIs are figured.

 Regards,
 Shinji

 2013/3/7 Shinji KOBAYASHI skoba at moss.gr.jp:

 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study
 more.

 Regards,

 2013/3/7 Diego Bosc? yampeku at gmail.com:

 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb

Regarding new CKM version webservice

[Sebastian Garde]

Hi Diego,

This - in itself - is actually correct I believe: it has moved there and 
the 301 response is the recommended way of having the old url still in 
place as far as I know.

You'll notice that in a browser this redirects correctly, e.g.
http://openehr.org/knowledge/services/ArchetypeFinderBean/ 
http://openehr.org/ckm/services/ArchetypeFinderBean/getAllArchetypeIdsWithPositioning?cursor=1size=10getArchetypeADLURL?archetypeId=openEHR-EHR-OBSERVATION.blood_pressure.v1
 
http://openehr.org/ckm/services/ArchetypeFinderBean/getArchetypeADLURL?archetypeId=openEHR-EHR-OBSERVATION.blood_pressure.v1

redirects from .../knowledge/... to .../ckm/... and then gives you the 
right response.

The problem is that e.g. the AE webservice client and likely others 
don't know what to do with this redirect (e.g. ask the user if they want 
to redirect or silently redirect).

We'll try to get the the webservice urls to silently redirect without 
giving a 301 response in between.

In any case, where it is possible, the webservice  URL should be updated 
to http://openehr.org/ckm/services/ArchetypeFinderBean?wsdl - saves you 
the redirect.

Cheers
Sebastian

On 07.03.2013 12:27, Diego Bosc? wrote:
 It gives a 301 code moved permanently
 http://en.wikipedia.org/wiki/HTTP_301

 2013/3/7 Ian McNicoll Ian.McNicoll at oceaninformatics.com:
 Hi Diego,

 I think this is technical hitch. The intention, AFAIK was to retain
 the original endpint, as well as adding the new one.

 Ian

 On 7 March 2013 10:35, Diego Bosc? yampeku at gmail.com wrote:
 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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


 --
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com

 Clinical Modelling Consultant, Ocean Informatics, UK
 Director openEHR Foundation  www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 SCIMP Working Group, NHS Scotland
 BCS Primary Health Care  www.phcsg.org

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


-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130307/b5c36a66/attachment.html

Regarding new CKM version webservice

[Sebastian Garde]

Hi Shinji,

I don't think anything has changed there (once it works again).

Regards
Sebastian

On 07.03.2013 14:43, Shinji KOBAYASHI wrote:
 Hi Sebastian,

 Thank you.

 I use getArchetypeIdsFromPartialId API to query archetypes by key word.
 Does web service APIs change?

 Regards,
 Shinji

 2013/3/7 Sebastian Garde sebastian.garde at oceaninformatics.com:
 Hi Shinji,

 No, they are certainly not obsolete.
 This was just a curly bracket that moved one up accidentally.
 I have fixed this locally and will be deploy asap.

 Cheers
 Sebastian


 On 07.03.2013 13:36, Shinji KOBAYASHI wrote:

 These web service APIs are not wroking now. Are they obsoleted?
 getArchetypeIdsFromPartialId
 getArchetypeIdsFromPartialIdWithPositioning
 getAllArchetypeIds
 getAllArchetypeIdsWithPositioning

 I would be very happy, if new APIs are figured.

 Regards,
 Shinji

 2013/3/7 Shinji KOBAYASHI skoba at moss.gr.jp:

 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study
 more.

 Regards,

 2013/3/7 Diego Bosc? yampeku at gmail.com:

 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130307/6768d2a5/attachment.html

Regarding new CKM version webservice

[Sebastian Garde]

These 4 webservices should work now as expected (using the /ckm url).
Sebastian

On 07.03.2013 15:58, Sebastian Garde wrote:
 Hi Shinji,

 I don't think anything has changed there (once it works again).

 Regards
 Sebastian

 On 07.03.2013 14:43, Shinji KOBAYASHI wrote:
 Hi Sebastian,

 Thank you.

 I use getArchetypeIdsFromPartialId API to query archetypes by key word.
 Does web service APIs change?

 Regards,
 Shinji

 2013/3/7 Sebastian Gardesebastian.garde at oceaninformatics.com:
 Hi Shinji,

 No, they are certainly not obsolete.
 This was just a curly bracket that moved one up accidentally.
 I have fixed this locally and will be deploy asap.

 Cheers
 Sebastian


 On 07.03.2013 13:36, Shinji KOBAYASHI wrote:

 These web service APIs are not wroking now. Are they obsoleted?
 getArchetypeIdsFromPartialId
 getArchetypeIdsFromPartialIdWithPositioning
 getAllArchetypeIds
 getAllArchetypeIdsWithPositioning

 I would be very happy, if new APIs are figured.

 Regards,
 Shinji

 2013/3/7 Shinji KOBAYASHIskoba at moss.gr.jp:

 Thank you, Diego.

 getArchetypeIdsFromPartialId API seems not working here, but I will study
 more.

 Regards,

 2013/3/7 Diego Bosc?yampeku at gmail.com:

 Hello all,

 Just to warn all potential CKM webservice users, CKM webservice
 endpoint has changed from
 'http://openehr.org/knowledge/services/.' to
 'http://openehr.org/ckm/services/..'
 Changing the endpoint solves the problem. The webservice itself seems
 to be the same. Are there any changes planed for it?

 Regards

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

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


 --

 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics

 Skype: gardeseb

 -- 
 *Dr. Sebastian Garde*
 /Dr. sc. hum., Dipl.-Inform. Med, FACHI/
 Senior Developer
 Ocean Informatics

 Skype: gardeseb


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

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130307/7b589fef/attachment.html

Regarding new CKM version webservice

[Diego Boscá]

Hello all,

Just to warn all potential CKM webservice users, CKM webservice
endpoint has changed from
'http://openehr.org/knowledge/services/.' to
'http://openehr.org/ckm/services/..'
Changing the endpoint solves the problem. The webservice itself seems
to be the same. Are there any changes planed for it?

Regards

Improvement suggestion to CKM Search

[Sebastian Garde]

Hi Pablo,

Thanks for the suggestion.
We actually used Levensthein in CKM's predessor tool (the Archeype Finder).
It required some finetuning to find  good matches, but then worked quite 
nicely.
Completely different technology now, but it may indeed be worth enabling 
something like this again.
It may be possible to get some suggestions on possible matches (Did you 
mean Glasgow?)
I need to check out the technical constraints a bit, but thank you again 
for your suggestion

Cheers
Sebastian

On 03.01.2013 22:34, pablo pazos wrote:
 Hi all,

 A couple of minutes ago I found the search in the CKM does an exact 
 string matching search. I would suggest to make a search based on 
 match weight using something like Levenshtein distance that is more 
 typo proof.

 (I typed Glasg*l*ow instead of Glasgow :)

 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos


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

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130105/04462ffb/attachment.html

Improvement suggestion to CKM Search

[pablo pazos]

Hi Sebastian,
Search suggestions are indeed a great feature for enhancing user experience!I'm 
glad to help :)

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Sat, 5 Jan 2013 11:12:39 +0100
From: sebastian.ga...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Improvement suggestion to CKM Search


  

  
  
Hi Pablo,



Thanks for the suggestion.

We actually used Levensthein in CKM's predessor tool (the Archeype
Finder).

It required some finetuning to find  good matches, but then worked
quite nicely. 

Completely different technology now, but it may indeed be worth
enabling something like this again.

It may be possible to get some suggestions on possible matches (Did
you mean Glasgow?)

I need to check out the technical constraints a bit, but thank you
again for your suggestion



Cheers

Sebastian



On 03.01.2013 22:34, pablo pazos wrote:



  
  
Hi all,



A couple of minutes ago I found the search in the CKM does
  an exact string matching search. I would suggest to make a
  search based on match weight using something like Levenshtein
  distance that is more typo proof.



(I typed Glasglow instead of Glasgow :)

  

  -- 

  Kind regards,

  Ing. Pablo Pazos Guti?rrez

  LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez

  Blog: http://informatica-medica.blogspot.com/

  Twitter: http://twitter.com/ppazos
  
  

  
  

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



-- 

   
  
  Dr. Sebastian Garde

  Dr. sc. hum., Dipl.-Inform. Med, FACHI

  Senior Developer

  Ocean Informatics

  

  Skype: gardeseb

  

  


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130105/bd379f15/attachment.html

Improvement suggestion to CKM Search

[pablo pazos]

Hi all,
A couple of minutes ago I found the search in the CKM does an exact string 
matching search. I would suggest to make a search based on match weight using 
something like Levenshtein distance that is more typo proof.
(I typed Glasglow instead of Glasgow :)

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130103/8e7c6fd6/attachment.html

openEHR website tip of the day - CKM comments

[Thomas Beale]

If you follow the link on the CKM news feed, i.e.



You go straight to the CKM comments in question:





-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121228/abee30a1/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: dcddhcca.png
Type: image/png
Size: 17362 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121228/abee30a1/attachment-0002.png
-- next part --
A non-text attachment was scrubbed...
Name: eggdgjed.png
Type: image/png
Size: 52410 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121228/abee30a1/attachment-0003.png

CKM archetypes for easy reference in ADL Workbench

[Thomas Beale]

I have uploaded a cleaned up version of the CKM archetypes, which nearly 
all compile cleanly in the ADL 1.5 workbench. (The reason why some 
cleaning was necessary is because the Workbench compiler is much 
stricter and better at checking even 1.4 level semantics than the tools 
used to build these archetypes in the first place). These archetypes are 
useful a) for making comparisons with other archetypes, e.g. 13606, 
CIMI, Intermountain etc and b) for seeing real clinical models made by 
real clinical people (not technicians!) and c) for learning the ADL 
Workbench.

The knowledge2 SVN repo is visible here - 
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ .

If you already have an SVN checkout for 
http://www.openehr.org/svn/knowledge2/TRUNK (or 
http://www.openehr.org/svn/knowledge2) then just do a normal 'SVN 
update'. If you don't have it, and know how to work with SVN, create a 
checkout of http://www.openehr.org/svn/knowledge2/TRUNK and you will get 
this CKM, CIMI, Intermountain and other repositories in one go. Each of 
those can be configured as a 'profile' in the workbench.

If you have no clue about SVN and want help, please post here and me or 
some other kind soul will help. It's easy when you know how.

In the web view of this SVN repo, it looks like this:



You can see that most compile here (just press F7 to do a compile once 
you are configured):



- thomas beale

*
*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121002/0c433bda/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: jhgghjbd.png
Type: image/png
Size: 17613 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121002/0c433bda/attachment-0002.png
-- next part --
A non-text attachment was scrubbed...
Name: feegfijf.png
Type: image/png
Size: 9635 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121002/0c433bda/attachment-0003.png

License for CKM icons?

[Diego Boscá]

Hello,

I have not been able to find the CKM specific icons license. Reading
the about page I know some icons come from Silk icons collection which
has a CC-BY license, which does not say anything about its current
license.
I have also read this page
(http://www.openehr.org/download/copyright.html), but I don't think
any of the points is talking really about this kind of resources (as
talks specifically about CKM archetypes, but not the other 'resources'
there)

Regards

License for CKM icons?

[Diego Boscá]

Thanks, the ones I was worried about were the model related ones. We
have a student working on a little project that I hope we can show
soon :)

2012/9/26 Thomas Beale thomas.beale at oceaninformatics.com:


 Diego,

 the icons here are the ones used in the ADL Workbench, which include the CKM
 model-related icons, but replace some of them with better ones. They are a
 superset of what you would need in CEN I guess, or you can use the CEN
 subset you find here. A lot of these are pretty rough!

 The AWB license is currently still the Mozilla tri-licence, but will change
 to the Apache license imminently.

 I think the most appropriate thing to do would be to remove these icons sets
 from the AWB, and put them in the knowledge2 SVN repository (or its Git
 successor) and license them under CC-BY.

 For practical purposes today, go ahead and use them.

 - thomas


 On 26/09/2012 09:13, Diego Bosc? wrote:

 Hello,

 I have not been able to find the CKM specific icons license. Reading
 the about page I know some icons come from Silk icons collection which
 has a CC-BY license, which does not say anything about its current
 license.
 I have also read this page
 (http://www.openehr.org/download/copyright.html
 ), but I don't think
 any of the points is talking really about this kind of resources (as
 talks specifically about CKM archetypes, but not the other 'resources'
 there)

 Regards

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



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

License for CKM icons?

[Thomas Beale]

On 26/09/2012 12:45, Diego Bosc? wrote:
 Thanks, the ones I was worried about were the model related ones. We
 have a student working on a little project that I hope we can show
 soon :)

 *
 *

I'll look into moving them into knowledge2 ASAP, but for now, just use 
'em

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120926/e6a5a7eb/attachment.html

Small CKM bug

[Sebastian Garde]

Hi Pablo,

With the next release, already opened archetype, template, termset, 
release set tabs (as well as the forthcoming project and incubator 
tabs), will be refreshed automatically on login, so that the rest of the 
buttons will appear automatically (and additional content etc. as well). 
Thank you for the suggestion!

Cheers
Sebastian


On 27.07.2012 09:00, Sebastian Garde wrote:
 Pablo,

 you can just click on any of the other buttons after you logged in and 
 the rest of the buttons will appear as well

 Sebastian

 On 27.07.2012 03:33, pablo pazos wrote:
 Hi,

 When I'm seeing an archetype without signing in, and later I sign in, 
 the archetype view (the one I'm seeing) is not updated with the 
 edition buttons (discussion, review, ...).
 When I open the archetype again, the buttons are there (I'm still 
 logged in).

 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos


 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

 -- 
 *Dr. Sebastian Garde*
 /Dr. sc. hum., Dipl.-Inform. Med, FACHI/
 Senior Developer
 Ocean Informatics

 Skype: gardeseb

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120822/e9e39358/attachment.html

Small CKM bug

[Sebastian Garde]

Pablo,

you can just click on any of the other buttons after you logged in and 
the rest of the buttons will appear as well

Sebastian

On 27.07.2012 03:33, pablo pazos wrote:
 Hi,

 When I'm seeing an archetype without signing in, and later I sign in, 
 the archetype view (the one I'm seeing) is not updated with the 
 edition buttons (discussion, review, ...).
 When I open the archetype again, the buttons are there (I'm still 
 logged in).

 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos


 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120727/44d955a7/attachment.html

Small CKM bug

[pablo pazos]

Hi,
When I'm seeing an archetype without signing in, and later I sign in, the 
archetype view (the one I'm seeing) is not updated with the edition buttons 
(discussion, review, ...).When I open the archetype again, the buttons are 
there (I'm still logged in).
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120726/9bcecf70/attachment.html

CKM Statistics

[Sebastian Garde]

Hi Pablo, 

We only show changes to the trunk in there, that is correct. 
Branches may be rejected or committed at any time and it is the trunk changes 
that count for most users.
For editors, there is also a list of active branches which is what you are 
after in this case.
This is also available for 'translation editors' which I think is the role you 
have taken on.
 We should give you that role on ckm as well then you can see this report if 
you like. We can also make it available to you offline. 
Cheers
Sebastian
(Sent from my phone.)

Am 30.06.2012 um 00:24 schrieb pablo pazos pazospablo at hotmail.com:

 Hi Sebastian,
 
 The RSS ad the New and Modifier archetypes seems to show only content 
 submitted by editors, not new translation branches.
 It would be very nice to have all the changes to archetypes, as in the 
 History area for each archetype, but in a list showing archetypes changed, 
 when and by who.
 
 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos
 
 Date: Fri, 29 Jun 2012 09:05:01 +0200
 From: sebastian.garde at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: Re: CKM Statistics
 
 Hi Pablo, 
 
 there is - in the current system - in the left hand panels there is one 
 called New and modified Archetypes where you can set the date since the 
 last change.
 A bit more comprehensively, on the Find resources tab in the center, open the 
 advanced section and set the Last modification on or after date.
 In addition to the Notification options mentioned by Heather, there is also 
 the ability to use CKM's RSS feed at http://openehr.org/knowledge/getRSS or 
 to follow CKM on twitter at https://twitter.com/#!/openEHRCKM
 
 Hope this helps,
 Cheers
 Sebastian
 
 On 29.06.2012 03:52, Heather Leslie wrote:
 Hi Pablo,
 
  
 
 Just a general reminder: any archetype that is still in draft or in review is 
 likely to change before publication, so any translation done on an archetype 
 in this state may need to be reworked or updated once the archetype is 
 published and the content is deemed stable. I say this as we are receiving 
 many translations that are much appreciated, but many will need revising at 
 some time in the future.
 
  
 
 To your specific question:
 
 ? Coming soon: the ability to see new and updated artefacts ? 
 archetypes, templates, ref sets and release sets. This is under development 
 as part of a significant upgrade to CKM. I?m looking at it now in our test 
 server. However there is no current plan to include who changed 
 them in this view, as it is available in the History as you note.
 
  
 
 ? Current functionality:  you can choose to activate notifications 
 per asset or in general via the ToolsOptionsNotifications tab ? where you 
 can select to be notified about New or updated assets per type plus new   
   comments to all discussions and new users. In these notifications 
 emails, the person who changed it is noted.
 
  
 
 For example, this is the resulting standard notification that I received on 
 an archetype update last week:
 
 Dear Heather Leslie,
 
 Archetype Nine Hole Peg Test (openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1) 
 has been updated by michael.braun.
 
 Log message: Changes to align with other MSFC archetypes, prior to first 
 review round.
 
 You have received this email because you have subscribed to be notified of 
 any changes to this archetype. You can now VIEW THE ARCHETYPE or visit the 
 Clinical Knowledge Manager Start Page (http://openehr.org/knowledge/)
 
  
 
 Regards
 
  
 
 Heather
 
  
 
 From: openehr-technical-bounces at lists.openehr.org 
 [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of pablo 
 pazos
 Sent: Friday, 29 June 2012 4:51 AM
 To: openEHR Clinical; openeh technical
 Subject: CKM Statistics
 
  
 
 Hi all,
 
  
 
 Just a quick question, is there any way to see recently changed archetypes 
 and by whom, all in the same screen?
 
  
 
 I know I can go to each archetype and see the history, but there are a lot of 
 archetypes and I can't go to each one to see if there are new changes.
 
  
 
 I need this because a lot of students on my course translated archetypes to 
 spanish and portuguese, and I would like to evaluate the real impact of the 
 openEHR course on archetype translation.
 
  
 
 Thanks!
 
 
 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos
 
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
 -- 
  
 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Senior Developer
 Ocean Informatics
 
 Skype

CKM Statistics

[pablo pazos]

Hi Sebastian,
Having a role to see branches would be fantastic.
Right now I'm not validating the translations, I'm just seeing the activity of 
my students to see who made what on the CKM and evaluating the impact of the 
openEHR on archetype translation to spanish  portuguese.

Let me know if I can have the role added to my profile.
Thanks a lot!Pablo.

CC: openehr-technical at lists.openehr.org
From: sebastian.ga...@oceaninformatics.com
Subject: Re: CKM Statistics
Date: Sat, 30 Jun 2012 15:48:38 +0200
To: openehr-technical at lists.openehr.org

Hi Pablo, 
We only show changes to the trunk in there, that is correct. Branches may be 
rejected or committed at any time and it is the trunk changes that count for 
most users.For editors, there is also a list of active branches which is what 
you are after in this case.This is also available for 'translation editors' 
which I think is the role you have taken on. We should give you that role on 
ckm as well then you can see this report if you like. We can also make it 
available to you offline. CheersSebastian(Sent from my phone.)
Am 30.06.2012 um 00:24 schrieb pablo pazos pazospablo at hotmail.com:





Hi Sebastian,
The RSS ad the New and Modifier archetypes seems to show only content submitted 
by editors, not new translation branches.It would be very nice to have all the 
changes to archetypes, as in the History area for each archetype, but in a list 
showing archetypes changed, when and by who.
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Fri, 29 Jun 2012 09:05:01 +0200
From: sebastian.ga...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: CKM Statistics


  

  
  
Hi Pablo, 



there is - in the current system - in the left hand panels there is
one called New and modified Archetypes where you can set the date
since the last change.

A bit more comprehensively, on the Find resources tab in the center,
open the advanced section and set the Last modification on or
after date.

In addition to the Notification options mentioned by Heather, there
is also the ability to use CKM's RSS feed at
http://openehr.org/knowledge/getRSS or to follow CKM on twitter at
https://twitter.com/#!/openEHRCKM



Hope this helps,

Cheers

Sebastian



On 29.06.2012 03:52, Heather Leslie
  wrote:



  
  
  
  
Hi
Pablo,
 
Just
a general reminder: any archetype that is still in draft or
in review is likely to change before publication, so any
translation done on an archetype in this state may need to
be reworked or updated once the archetype is published and
the content is deemed stable. I say this as we are receiving
many translations that are much appreciated, but many will
need revising at some time in the future.
 
To
your specific question:
? Coming
soon: the ability to see new and updated artefacts ?
archetypes, templates, ref sets and release sets. This is
under development as part of a significant upgrade to CKM.
I?m looking at it now in our test server. However there is
no current plan to include who changed them in this view, as
it is available in the History as you note.
 
? Current
functionality:  you can choose to activate notifications per
asset or in general via the
ToolsOptionsNotifications tab ? where you can select
to be notified about New or updated assets per type plus new
comments to all discussions and new users. In these
notifications emails, the person who changed it is noted.
 
For
example, this is the resulting standard notification that I
received on an archetype update last week:
Dear Heather Leslie,
Archetype Nine Hole Peg Test
  (openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1) has been
  updated by michael.braun.
Log message: Changes to align with
  other MSFC archetypes, prior to first review round.
You have received this email
  because you have subscribed to be notified of any changes to
  this archetype. You can now VIEW
THE ARCHETYPE or visit the Clinical Knowledge
Manager Start Page (http://openehr.org/knowledge/)
 
Regards
 
Heather
 

  
From:
openehr-technical-bounces at lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On
  Behalf Of pablo pazos

Sent: Friday

CKM Statistics

[Ian McNicoll]

Hi

Ian

Dr Ian McNicoll
Clinical modelling consultant Ocean Informatics
Mobile +44 (0) 775 209 7859
Skype imcnicoll

On 30 Jun 2012, at 18:16, pablo pazos pazospablo at hotmail.com wrote:

 Hi Sebastian,

Having a role to see branches would be fantastic.

Right now I'm not validating the translations, I'm just seeing the activity
of my students to see who made what on the CKM and evaluating the impact of
the openEHR on archetype translation to spanish  portuguese.

Let me know if I can have the role added to my profile.

Thanks a lot!
Pablo.

--
CC: openehr-technical at lists.openehr.org
From: sebastian.ga...@oceaninformatics.com
Subject: Re: CKM Statistics
Date: Sat, 30 Jun 2012 15:48:38 +0200
To: openehr-technical at lists.openehr.org

Hi Pablo,

We only show changes to the trunk in there, that is correct.
Branches may be rejected or committed at any time and it is the trunk
changes that count for most users.
For editors, there is also a list of active branches which is what you are
after in this case.
This is also available for 'translation editors' which I think is the role
you have taken on.
 We should give you that role on ckm as well then you can see this report
if you like. We can also make it available to you offline.
Cheers
Sebastian
(Sent from my phone.)

Am 30.06.2012 um 00:24 schrieb pablo pazos pazospablo at hotmail.com:

 Hi Sebastian,

The RSS ad the New and Modifier archetypes seems to show only content
submitted by editors, not new translation branches.
It would be very nice to have all the changes to archetypes, as in the
History area for each archetype, but in a list showing archetypes changed,
when and by who.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos http://twitter.com/ppazos

--
Date: Fri, 29 Jun 2012 09:05:01 +0200
From: sebastian.ga...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: CKM Statistics

Hi Pablo,

there is - in the current system - in the left hand panels there is one
called New and modified Archetypes where you can set the date since the
last change.
A bit more comprehensively, on the Find resources tab in the center, open
the advanced section and set the Last modification on or after date.
In addition to the Notification options mentioned by Heather, there is also
the ability to use CKM's RSS feed at http://openehr.org/knowledge/getRSS or
to follow CKM on twitter at https://twitter.com/#!/openEHRCKM

Hope this helps,
Cheers
Sebastian

On 29.06.2012 03:52, Heather Leslie wrote:

 Hi Pablo,



Just a general reminder: any archetype that is still in draft or in review
is likely to change before publication, so any translation done on an
archetype in this state may need to be reworked or updated once the
archetype is published and the content is deemed stable. I say this as we
are receiving many translations that are much appreciated, but many will
need revising at some time in the future.



To your specific question:

? Coming soon: the ability to see new and updated artefacts ?
archetypes, templates, ref sets and release sets. This is under development
as part of a significant upgrade to CKM. I?m looking at it now in our test
server. However there is no current plan to include who changed them in
this view, as it is available in the History as you note.



? Current functionality:  you can choose to activate notifications
per asset or in general via the ToolsOptionsNotifications tab ? where you
can select to be notified about New or updated assets per type plus new
comments to all discussions and new users. In these notifications emails,
the person who changed it is noted.



For example, this is the resulting standard notification that I received on
an archetype update last week:

Dear Heather Leslie,

Archetype Nine Hole Peg Test
(openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1) has been updated by
michael.braun.

Log message: Changes to align with other MSFC archetypes, prior to first
review round.

You have received this email because you have subscribed to be notified of
any changes to this archetype. You can now VIEW THE
ARCHETYPEhttp://openehr.org/knowledge/#showArchetype_1013.1.1202or
visit the Clinical
Knowledge Manager Start Page http://openehr.org/knowledge/ (
http://openehr.org/knowledge/)



Regards



Heather



*From:* openehr-technical-bounces at lists.openehr.org [
mailto:openehr-technical-bounces at lists.openehr.orgopenehr-technical-bounces 
at lists.openehr.org]
*On Behalf Of *pablo pazos
*Sent:* Friday, 29 June 2012 4:51 AM
*To:* openEHR Clinical; openeh technical
*Subject:* CKM Statistics



Hi all,



Just a quick question, is there any way to see recently changed archetypes
and by whom, all in the same screen?



I know I can go to each archetype and see the history, but there are a lot
of archetypes and I

CKM Statistics

[Heather Leslie]

Hi Pablo,

 

Just a general reminder: any archetype that is still in draft or in review
is likely to change before publication, so any translation done on an
archetype in this state may need to be reworked or updated once the
archetype is published and the content is deemed stable. I say this as we
are receiving many translations that are much appreciated, but many will
need revising at some time in the future.

 

To your specific question:

? Coming soon: the ability to see new and updated artefacts ?
archetypes, templates, ref sets and release sets. This is under development
as part of a significant upgrade to CKM. I?m looking at it now in our test
server. However there is no current plan to include who changed them in this
view, as it is available in the History as you note.

 

? Current functionality:  you can choose to activate notifications
per asset or in general via the ToolsOptionsNotifications tab ? where you
can select to be notified about New or updated assets per type plus new
comments to all discussions and new users. In these notifications emails,
the person who changed it is noted.

 

For example, this is the resulting standard notification that I received on
an archetype update last week:

Dear Heather Leslie,

Archetype Nine Hole Peg Test (openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1)
has been updated by michael.braun.

Log message: Changes to align with other MSFC archetypes, prior to first
review round.

You have received this email because you have subscribed to be notified of
any changes to this archetype. You can now VIEW THE ARCHETYPE
http://openehr.org/knowledge/#showArchetype_1013.1.1202  or visit the
Clinical Knowledge Manager Start Page http://openehr.org/knowledge/
(http://openehr.org/knowledge/)

 

Regards

 

Heather

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of pablo
pazos
Sent: Friday, 29 June 2012 4:51 AM
To: openEHR Clinical; openeh technical
Subject: CKM Statistics

 

Hi all,

 

Just a quick question, is there any way to see recently changed archetypes
and by whom, all in the same screen?

 

I know I can go to each archetype and see the history, but there are a lot
of archetypes and I can't go to each one to see if there are new changes.

 

I need this because a lot of students on my course translated archetypes to
spanish and portuguese, and I would like to evaluate the real impact of the
openEHR course on archetype translation.

 

Thanks!


-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120629/58733fcd/attachment-0001.html

CKM Statistics

[Sebastian Garde]

Hi Pablo,

there is - in the current system - in the left hand panels there is one 
called New and modified Archetypes where you can set the date since 
the last change.
A bit more comprehensively, on the Find resources tab in the center, 
open the advanced section and set the Last modification on or after date.
In addition to the Notification options mentioned by Heather, there is 
also the ability to use CKM's RSS feed at 
http://openehr.org/knowledge/getRSS or to follow CKM on twitter at 
https://twitter.com/#!/openEHRCKM

Hope this helps,
Cheers
Sebastian

On 29.06.2012 03:52, Heather Leslie wrote:

 Hi Pablo,

 Just a general reminder: any archetype that is still in draft or in 
 review is likely to change before publication, so any translation done 
 on an archetype in this state may need to be reworked or updated once 
 the archetype is published and the content is deemed stable. I say 
 this as we are receiving many translations that are much appreciated, 
 but many will need revising at some time in the future.

 To your specific question:

 ?Coming soon: the ability to see new and updated artefacts -- 
 archetypes, templates, ref sets and release sets. This is under 
 development as part of a significant upgrade to CKM. I'm looking at it 
 now in our test server. However there is no current plan to include 
 who changed them in this view, as it is available in the History as 
 you note.

 ?Current functionality:  you can choose to activate notifications per 
 asset or in general via the ToolsOptionsNotifications tab -- where 
 you can select to be notified about New or updated assets per type 
 plus new comments to all discussions and new users. In these 
 notifications emails, the person who changed it is noted.

 For example, this is the resulting standard notification that I 
 received on an archetype update last week:

 Dear Heather Leslie,

 Archetype Nine Hole Peg Test 
 (openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1) has been updated by 
 michael.braun.

 Log message: Changes to align with other MSFC archetypes, prior to 
 first review round.

 You have received this email because you have subscribed to be 
 notified of any changes to this archetype. You can now VIEW THE 
 ARCHETYPE http://openehr.org/knowledge/#showArchetype_1013.1.1202 or 
 visit the Clinical Knowledge Manager Start Page 
 http://openehr.org/knowledge/ (http://openehr.org/knowledge/)

 Regards

 Heather

 *From:*openehr-technical-bounces at lists.openehr.org 
 [mailto:openehr-technical-bounces at lists.openehr.org] *On Behalf Of 
 *pablo pazos
 *Sent:* Friday, 29 June 2012 4:51 AM
 *To:* openEHR Clinical; openeh technical
 *Subject:* CKM Statistics

 Hi all,

 Just a quick question, is there any way to see recently changed 
 archetypes and by whom, all in the same screen?

 I know I can go to each archetype and see the history, but there are a 
 lot of archetypes and I can't go to each one to see if there are new 
 changes.

 I need this because a lot of students on my course translated 
 archetypes to spanish and portuguese, and I would like to evaluate the 
 real impact of the openEHR course on archetype translation.

 Thanks!


 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos



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

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120629/b3c20174/attachment.html

CKM Statistics

[pablo pazos]

Hi Heather,
I know, clinical modelling is a process and on refactoring some rework should 
be done (is the same with software source code).
The good news are that I have an *army of translators* to spanish and 
portuguese (my guess is more than 20 archetypes where translated to spanish or 
portuguese on the CKM by my students in about two weeks ago).

I hope the new statistics funcionality come out soon because registering to 
receive notifications on 200+ archetypes one by one is a pain in the a$$.
I'm subscribed to the RSS of the CKM, but it only seem to show content 
submitted by editors, not new translation branches.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

From: heather.les...@oceaninformatics.com
To: openehr-technical at lists.openehr.org; openehr-clinical at 
lists.openehr.org
Subject: RE: CKM Statistics
Date: Fri, 29 Jun 2012 11:52:26 +1000

Hi Pablo, Just a general reminder: any archetype that is still in draft or in 
review is likely to change before publication, so any translation done on an 
archetype in this state may need to be reworked or updated once the archetype 
is published and the content is deemed stable. I say this as we are receiving 
many translations that are much appreciated, but many will need revising at 
some time in the future. To your specific question:? Coming soon: the 
ability to see new and updated artefacts ? archetypes, templates, ref sets and 
release sets. This is under development as part of a significant upgrade to 
CKM. I?m looking at it now in our test server. However there is no current plan 
to include who changed them in this view, as it is available in the History as 
you note. ? Current functionality:  you can choose to activate 
notifications per asset or in general via the ToolsOptionsNotifications tab ? 
where you can select to be notified about New or updated assets per type plus 
new comments to all discussions and new users. In these notifications emails, 
the person who changed it is noted. For example, this is the resulting standard 
notification that I received on an archetype update last week:Dear Heather 
Leslie,Archetype Nine Hole Peg Test 
(openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1) has been updated by 
michael.braun.Log message: Changes to align with other MSFC archetypes, prior 
to first review round.You have received this email because you have subscribed 
to be notified of any changes to this archetype. You can now VIEW THE ARCHETYPE 
or visit the Clinical Knowledge Manager Start Page 
(http://openehr.org/knowledge/) Regards Heather From: openehr-technical-bounces 
at lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Friday, 29 June 2012 4:51 AM
To: openEHR Clinical; openeh technical
Subject: CKM Statistics Hi all, Just a quick question, is there any way to see 
recently changed archetypes and by whom, all in the same screen? I know I can 
go to each archetype and see the history, but there are a lot of archetypes and 
I can't go to each one to see if there are new changes. I need this because a 
lot of students on my course translated archetypes to spanish and portuguese, 
and I would like to evaluate the real impact of the openEHR course on archetype 
translation. Thanks!
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120629/c42ba8cf/attachment.html

CKM Statistics

[pablo pazos]

Hi Sebastian,
The RSS ad the New and Modifier archetypes seems to show only content submitted 
by editors, not new translation branches.It would be very nice to have all the 
changes to archetypes, as in the History area for each archetype, but in a list 
showing archetypes changed, when and by who.
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Fri, 29 Jun 2012 09:05:01 +0200
From: sebastian.ga...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: CKM Statistics


  

  
  
Hi Pablo, 



there is - in the current system - in the left hand panels there is
one called New and modified Archetypes where you can set the date
since the last change.

A bit more comprehensively, on the Find resources tab in the center,
open the advanced section and set the Last modification on or
after date.

In addition to the Notification options mentioned by Heather, there
is also the ability to use CKM's RSS feed at
http://openehr.org/knowledge/getRSS or to follow CKM on twitter at
https://twitter.com/#!/openEHRCKM



Hope this helps,

Cheers

Sebastian



On 29.06.2012 03:52, Heather Leslie
  wrote:



  
  
  
  
Hi
Pablo,
 
Just
a general reminder: any archetype that is still in draft or
in review is likely to change before publication, so any
translation done on an archetype in this state may need to
be reworked or updated once the archetype is published and
the content is deemed stable. I say this as we are receiving
many translations that are much appreciated, but many will
need revising at some time in the future.
 
To
your specific question:
? Coming
soon: the ability to see new and updated artefacts ?
archetypes, templates, ref sets and release sets. This is
under development as part of a significant upgrade to CKM.
I?m looking at it now in our test server. However there is
no current plan to include who changed them in this view, as
it is available in the History as you note.
 
? Current
functionality:  you can choose to activate notifications per
asset or in general via the
ToolsOptionsNotifications tab ? where you can select
to be notified about New or updated assets per type plus new
comments to all discussions and new users. In these
notifications emails, the person who changed it is noted.
 
For
example, this is the resulting standard notification that I
received on an archetype update last week:
Dear Heather Leslie,
Archetype Nine Hole Peg Test
  (openEHR-EHR-OBSERVATION.nine_hole_peg_test.v1) has been
  updated by michael.braun.
Log message: Changes to align with
  other MSFC archetypes, prior to first review round.
You have received this email
  because you have subscribed to be notified of any changes to
  this archetype. You can now VIEW
THE ARCHETYPE or visit the Clinical Knowledge
Manager Start Page (http://openehr.org/knowledge/)
 
Regards
 
Heather
 

  
From:
openehr-technical-bounces at lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On
  Behalf Of pablo pazos

Sent: Friday, 29 June 2012 4:51 AM

To: openEHR Clinical; openeh technical

Subject: CKM Statistics
  

 

  

  Hi
  all,


   


  Just
  a quick question, is there any way to see recently
  changed archetypes and by whom, all in the same
  screen?


   


  I
  know I can go to each archetype and see the history,
  but there are a lot of archetypes and I can't go to
  each one to see if there are new changes.


   


  I
  need this because a lot of students on my course
  translated archetypes to spanish and portuguese, and I
  would like to evaluate the real impact of the openEHR
  course on archetype translation

CKM Statistics

[pablo pazos]

Hi all,
Just a quick question, is there any way to see recently changed archetypes and 
by whom, all in the same screen?
I know I can go to each archetype and see the history, but there are a lot of 
archetypes and I can't go to each one to see if there are new changes.
I need this because a lot of students on my course translated archetypes to 
spanish and portuguese, and I would like to evaluate the real impact of the 
openEHR course on archetype translation.
Thanks!
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120628/0cc37af4/attachment.html

technical problem CKM

[Bert Verhees]

Hi,

I think there is some problem in:
http://www.openehr.org/knowledge/

Schemes could not be retrieved. Please check your selection and that you 
have appropriate rights.
Release sets could not be loaded.
Termsets could not be loaded
The teams could not be retrieved.
The templates could not be loaded.
Archetypes could not be retrieved.

etc

Looks like a part of the application went offline

Thanks
Bert Verhees

technical problem CKM

[Sebastian Garde]

Hi Bert,

The server has gone down for some reason.
Should be working again now.

Sebastian


On 23.06.2012 12:15, Bert Verhees wrote:
 Hi,

 I think there is some problem in:
 http://www.openehr.org/knowledge/

 Schemes could not be retrieved. Please check your selection and that 
 you have appropriate rights.
 Release sets could not be loaded.
 Termsets could not be loaded
 The teams could not be retrieved.
 The templates could not be loaded.
 Archetypes could not be retrieved.

 etc

 Looks like a part of the application went offline

 Thanks
 Bert Verhees

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



-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120623/c8930f9b/attachment.html

CKM errors

[Sebastian Garde]

Hi Diego,

thanks, yes, we are working on it.
It is simply the licence file that has expired.

Regards
Sebastian

On 02.04.2012 10:09, Diego Bosc? wrote:
 Seems that there is some problem with CKM, as even if webpage loads, 
 following errors are thrown:

 Archetypes could not be retrieved.
 The teams could not be retrieved.
 Schemes could not be retrieved. Please check your selection and that 
 you have appropriate rights.
 Release sets could not be loaded.
 Termsets could not be loaded
 The templates could not be loaded.
 Could not load generic reference model info
 User configuration could not be retrieved.

 also, web services for CKM don't work either (I assume the reason 
 being the same as above)


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

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120402/7f70f60a/attachment.html

CKM errors

[Sebastian Garde]

Hi Diego,

The issue has been resolved.

Cheers
Sebastian

On 02.04.2012 10:16, Sebastian Garde wrote:
 Hi Diego,

 thanks, yes, we are working on it.
 It is simply the licence file that has expired.

 Regards
 Sebastian

 On 02.04.2012 10:09, Diego Bosc? wrote:
 Seems that there is some problem with CKM, as even if webpage loads, 
 following errors are thrown:

 Archetypes could not be retrieved.
 The teams could not be retrieved.
 Schemes could not be retrieved. Please check your selection and that 
 you have appropriate rights.
 Release sets could not be loaded.
 Termsets could not be loaded
 The templates could not be loaded.
 Could not load generic reference model info
 User configuration could not be retrieved.

 also, web services for CKM don't work either (I assume the reason 
 being the same as above)


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

 -- 
 *Dr. Sebastian Garde*
 /Dr. sc. hum., Dipl.-Inform. Med, FACHI/
 Senior Developer
 Ocean Informatics

 Skype: gardeseb


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

-- 
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics

Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120402/17fbb855/attachment.html

CKM errors

[Diego Boscá]

Seems that there is some problem with CKM, as even if webpage loads,
following errors are thrown:

Archetypes could not be retrieved.
The teams could not be retrieved.
Schemes could not be retrieved. Please check your selection and that you
have appropriate rights.
Release sets could not be loaded.
Termsets could not be loaded
The templates could not be loaded.
Could not load generic reference model info
User configuration could not be retrieved.

also, web services for CKM don't work either (I assume the reason being the
same as above)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120402/5210cd4b/attachment.html

How to get the URL to an archetype on the CKM?

[pablo pazos]

Thanks a lot for your answers! Helped me a lot.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

 From: Ian.McNicoll at oceaninformatics.com
 Date: Thu, 26 Jan 2012 16:00:56 +
 Subject: Re: How to get the URL to an archetype on the CKM?
 To: openehr-technical at openehr.org
 CC: openehr-clinical at openehr.org
 
 Hi Pablo,
 
 Open the archetype and press the share with colleague button (Envelope
 icon) this gives you a few options.
 
 Ian
 
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 
 Clinical Modelling Consultant, Ocean Informatics, UK
 Director/Clinical Knowledge Editor openEHR Foundation  
 www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 SCIMP Working Group, NHS Scotland
 BCS Primary Health Care  www.phcsg.org
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120127/c34e786a/attachment.html

How to get the URL to an archetype on the CKM?

[pablo pazos]

Hi,
When I want to show an archetype to someone I have to tell him/her to go to the 
CKM and do some search.Is there any way to get an URL to display one archetype 
on the CKM?

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/23dd030e/attachment.html

How to get the URL to an archetype on the CKM?

[Sebastian Garde]

Hi Pablo,

sure, the easiest is probably to go to the Share with Colleague Tab 
for that archetype.
You'll find a) the direct URL to this archetype which you can copy or 
share using AddToAny and b) use the form to send it directly.

For details like referring to a specific revision of the archetype, or 
opening a specific view (e.g. the Mindmap view) see 
http://www.openehr.org/wiki/display/healthmod/Opening+a+Resource+on+CKM+Start

Regards
Sebastian

On 26.01.2012 16:42, pablo pazos wrote:
 Hi,

 When I want to show an archetype to someone I have to tell him/her to 
 go to the CKM and do some search.
 Is there any way to get an URL to display one archetype on the CKM?

 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/50e764e6/attachment.html

How to get the URL to an archetype on the CKM?

[Diego Boscá]

Hello Pablo,

The way for accessing an archetype on the CKM from an URL is to build
a URL similar to this

http://www.openehr.org/knowledge/#showArchetypeById_openEHR-EHR-OBSERVATION.lab_test-lipids.v1
http://www.openehr.org/knowledge/#showArchetypeById_openEHR-EHR-OBSERVATION.lab_test-full_blood_count.v1

Regards

2012/1/26 pablo pazos pazospablo at hotmail.com:
 Hi,

 When I want to show an archetype to someone I have to tell him/her to go to
 the CKM and do some search.
 Is there any way to get an URL to display one archetype on the CKM?

 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

How to get the URL to an archetype on the CKM?

[Ian McNicoll]

Hi Pablo,

Open the archetype and press the share with colleague button (Envelope
icon) this gives you a few options.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant,?Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care ?www.phcsg.org



On 26 January 2012 15:42, pablo pazos pazospablo at hotmail.com wrote:
 Hi,

 When I want to show an archetype to someone I have to tell him/her to go to
 the CKM and do some search.
 Is there any way to get an URL to display one archetype on the CKM?

 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

CKM new Release

[Sebastian Garde]

Dear all,

We have released a new version of CKM - up and running at 
openehr.org/knowledge

The 1.1.5 release of CKM is a release that contains some major new 
functionality and some minor usability changes and bugfixes.
Most prominently, it features the newly developed review functionality 
for terminology subsets (termsets) within CKM following a similar 
process to the currently available archetype content reviews.
Some new functionality has been integrated into this release in an 
effort to streamline some of the tasks for CKM editors: For example, 
there is a new admin report on active branches of all resources that 
helps in keeping track of current (and outdated) activity. Also there is 
a new overview of users with a certain CKM-wide role (e.g. all 
administrators) and editors are now able to upload to branches that have 
not originally been checked out by them (used e.g. for merging). This 
release does not contain any major changes to the user experience but 
finetunes some aspects of user interaction, display and the handling of 
revisions.

You can find all the details here:
http://www.openehr.org/wiki/display/healthmod/CKM+Release+1.1.5

If you notice any oddities, please let me know!

Best regards
Sebastian

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Sebastian Garde]

Hi Athanasios,

I have updated CKM, hopefully fixing this issue.
Let me know if this is working for you now

Regards
Sebastian


Am 06.09.2011 11:49, schrieb Athanasios Anastasiou:
 Hello

 Thank you for your response Sebastian.

 Is it a small number of changes that i could perhaps apply to the XSDs 
 temporarily or better wait for you to modify the serialiser and try to 
 re-download the archetypes from the CKM?

 All the best
 Athanasios Anastasiou




 On 06/09/2011 09:53, Sebastian Garde wrote:
 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
 Hello everyone

 Maybe there has been some intermediate change that i am missing here 
 but
 i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available 
 XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html 
 and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files? And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it 
 makes
 a difference for case sensitive file systems :-)

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Athanasios Anastasiou]

Hello Sebastian

First of all, many thanks for the quick response.

I have just given it one more try and it generates less errors:

The complaints currently are:
No child element expected at this point for property and 
terminology_id and that C_CODE_PHRASE and C_DV_QUANTITY can not be 
resolved because the type definition can not be abstract for element 
children.

I hope this helps.

All the best
Athanasios



On 07/09/2011 11:04, Sebastian Garde wrote:
 Hi Athanasios,

 I have updated CKM, hopefully fixing this issue.
 Let me know if this is working for you now

 Regards
 Sebastian


 Am 06.09.2011 11:49, schrieb Athanasios Anastasiou:
 Hello

 Thank you for your response Sebastian.

 Is it a small number of changes that i could perhaps apply to the XSDs
 temporarily or better wait for you to modify the serialiser and try to
 re-download the archetypes from the CKM?

 All the best
 Athanasios Anastasiou




 On 06/09/2011 09:53, Sebastian Garde wrote:
 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
 Hello everyone

 Maybe there has been some intermediate change that i am missing here
 but
 i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available
 XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html
 and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files? And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it
 makes
 a difference for case sensitive file systems :-)

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Athanasios Anastasiou]

Hello Sebastian

Many thanks, that was indeed the problem.

I thought all necessary data structures would be referenced through the 
Archetype.xsd at some point.

All the best
Athanasios Anastasiou




On 07/09/2011 12:38, Sebastian Garde wrote:
 Hi,

 Is it possible that these errors occur because you are using
 archetype.xsd as your top-level schema?
 In that case, try using the OpenehrProfile.xsd as the top-level schema
 instead (which then includes the archetype.xsd).
 The openehr profile defines the extra C_CODE_PHRASE and C_DV_QUANTITY
 (and a couple others)

 Cheers
 Sebastian

 Am 07.09.2011 13:13, schrieb Athanasios Anastasiou:
 Hello Sebastian

 First of all, many thanks for the quick response.

 I have just given it one more try and it generates less errors:

 The complaints currently are:
 No child element expected at this point for property and
 terminology_id and that C_CODE_PHRASE and C_DV_QUANTITY can not be
 resolved because the type definition can not be abstract for element
 children.

 I hope this helps.

 All the best
 Athanasios



 On 07/09/2011 11:04, Sebastian Garde wrote:
 Hi Athanasios,

 I have updated CKM, hopefully fixing this issue.
 Let me know if this is working for you now

 Regards
 Sebastian


 Am 06.09.2011 11:49, schrieb Athanasios Anastasiou:
 Hello

 Thank you for your response Sebastian.

 Is it a small number of changes that i could perhaps apply to the XSDs
 temporarily or better wait for you to modify the serialiser and try to
 re-download the archetypes from the CKM?

 All the best
 Athanasios Anastasiou




 On 06/09/2011 09:53, Sebastian Garde wrote:
 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some
 elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to
 fix.

 Is anybody maintaining this code at present? Otherwise I can have a
 go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
 Hello everyone

 Maybe there has been some intermediate change that i am missing here
 but
 i am trying to validate
 openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available
 XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html
 and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files?
 And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd
 instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it
 makes
 a difference for case sensitive file systems :-)




 --
 Ocean Informatics 
 Dr Sebastian Garde
 Senior Developer
 Ocean Informatics

 /Dr. sc. hum., Dipl.-Inform. Med, FACHI/

 Skype: gardeseb

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Sebastian Garde]

Hi

CKM is using the XML serialiser of the openEHR Java Reference 
implementation.

It seems that the serialiser applies a different order to some elements 
than required by the schema.

Not sure if these were turned around in the xsd at some stage maybe?
While I don't really understand why these elements need to have an 
order, I believe the problem in the XML serialiser is quite easy to fix.

Is anybody maintaining this code at present? Otherwise I can have a go.

Regards
Sebastian


Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
 Hello everyone

 Maybe there has been some intermediate change that i am missing here but
 i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files? And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes
 a difference for case sensitive file systems :-)



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Rong Chen]

Hi Sebastian,

To my knowledge, no one is maintaining the AOM xml-serialiser from the Java
Reference Project at the moment. So I would appreciate if you could fix it
this time.

Actually the larger issue about xml-serialiser is that it's not relying on a
java XML binding API. This makes it vulnarable to changes in the archetype
XML schema.

There is already a xml-binding component that provides XML parsing and
serialising based on RM XML schema. One just needs to implement a mapping
between the classes from  openehr-aom component and the generated XML
binding classes in order to have XML schema based parsing and serialising.
This is probably the best way to go.

Cheers,
Rong

On 6 September 2011 10:53, Sebastian Garde 
sebastian.garde at oceaninformatics.com wrote:

 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
  Hello everyone
 
  Maybe there has been some intermediate change that i am missing here but
  i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
  (downloaded as XML from the CKM editor today) through the available XSDs
  from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and
  i am getting a very large number of errors.
 
  Just as an indication, all the errors are Invalid content was found
  mostly for the elements existence and lower_included (expecting
  rm_attribute_name and lower_unbounded respectively)
 
  Are there different XSDs for the structure of the CKM XML files? And if
  yes, are they available?
 
  Looking forward to hearing from you
  Athanasios Anastasiou
 
  P.S. Just as a note, Resource.xsd references basetypes.xsd instead
  of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
  BaseTypes.xsd in version 1.0). It seems that the intention is to
  preserve the letter case (e.g. the Resource.xsd and Structure.xsd
  reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes
  a difference for case sensitive file systems :-)
 
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/07084cc8/attachment.html

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Seref Arikan]

Hi Rong,
I'm working on this; an AOM to JAXB binding. I'm hoping that I'll be
able to give more details in a couple of weeks.

Regards
Seref


On Tue, Sep 6, 2011 at 10:34 AM, Rong Chen rong.acode at gmail.com wrote:
 Hi Sebastian,
 To my knowledge, no one is maintaining the AOM xml-serialiser from the Java
 Reference Project at the moment. So I would appreciate if you could fix it
 this time.
 Actually the larger issue about xml-serialiser is that it's not relying on a
 java XML binding API. This makes it vulnarable to changes in the archetype
 XML schema.
 There is already a xml-binding component that provides XML parsing and
 serialising based on RM XML schema. One just needs to implement a mapping
 between the classes from ?openehr-aom component and the generated XML
 binding classes in order to have XML schema based parsing and serialising.
 This is probably the best way to go.
 Cheers,
 Rong
 On 6 September 2011 10:53, Sebastian Garde
 sebastian.garde at oceaninformatics.com wrote:

 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
  Hello everyone
 
  Maybe there has been some intermediate change that i am missing here but
  i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
  (downloaded as XML from the CKM editor today) through the available XSDs
  from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and
  i am getting a very large number of errors.
 
  Just as an indication, all the errors are Invalid content was found
  mostly for the elements existence and lower_included (expecting
  rm_attribute_name and lower_unbounded respectively)
 
  Are there different XSDs for the structure of the CKM XML files? And if
  yes, are they available?
 
  Looking forward to hearing from you
  Athanasios Anastasiou
 
  P.S. Just as a note, Resource.xsd references basetypes.xsd instead
  of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
  BaseTypes.xsd in version 1.0). It seems that the intention is to
  preserve the letter case (e.g. the Resource.xsd and Structure.xsd
  reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes
  a difference for case sensitive file systems :-)
 
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Sebastian Garde]

I believe it would be a very limited number of changes. If this helps 
you temporarily, I'd go for it.
Sebastian

Am 06.09.2011 11:49, schrieb Athanasios Anastasiou:
 Hello

 Thank you for your response Sebastian.

 Is it a small number of changes that i could perhaps apply to the XSDs 
 temporarily or better wait for you to modify the serialiser and try to 
 re-download the archetypes from the CKM?

 All the best
 Athanasios Anastasiou




 On 06/09/2011 09:53, Sebastian Garde wrote:
 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
 Hello everyone

 Maybe there has been some intermediate change that i am missing here 
 but
 i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available 
 XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html 
 and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files? And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it 
 makes
 a difference for case sensitive file systems :-)



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



-- 
Ocean Informatics   
Dr Sebastian Garde
Senior Developer
Ocean Informatics

/Dr. sc. hum., Dipl.-Inform. Med, FACHI/

Skype: gardeseb

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/ac205189/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: oceanlogo.png
Type: image/png
Size: 5677 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/ac205189/attachment.png

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Sebastian Garde]

Hi,

I have modified the XMLSerialiser code and checked it in, you can 
compile it from there if you like.
This will become part of the next minor release for ckm.

Seref: looking forward to the binding!

Cheers
Sebastian

Am 06.09.2011 11:44, schrieb Seref Arikan:
 Hi Rong,
 I'm working on this; an AOM to JAXB binding. I'm hoping that I'll be
 able to give more details in a couple of weeks.

 Regards
 Seref


 On Tue, Sep 6, 2011 at 10:34 AM, Rong Chenrong.acode at gmail.com  wrote:
 Hi Sebastian,
 To my knowledge, no one is maintaining the AOM xml-serialiser from the Java
 Reference Project at the moment. So I would appreciate if you could fix it
 this time.
 Actually the larger issue about xml-serialiser is that it's not relying on a
 java XML binding API. This makes it vulnarable to changes in the archetype
 XML schema.
 There is already a xml-binding component that provides XML parsing and
 serialising based on RM XML schema. One just needs to implement a mapping
 between the classes from  openehr-aom component and the generated XML
 binding classes in order to have XML schema based parsing and serialising.
 This is probably the best way to go.
 Cheers,
 Rong
 On 6 September 2011 10:53, Sebastian Garde
 sebastian.garde at oceaninformatics.com  wrote:
 Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:
 Hello everyone

 Maybe there has been some intermediate change that i am missing here but
 i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files? And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes
 a difference for case sensitive file systems :-)



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- 
Ocean Informatics   
Dr Sebastian Garde
Senior Developer
Ocean Informatics

/Dr. sc. hum., Dipl.-Inform. Med, FACHI/

Skype: gardeseb

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/d82fc4f5/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: oceanlogo.png
Type: image/png
Size: 5677 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/d82fc4f5/attachment.png

CKM Archetypes in XML don't seem to validate properly against available XSDs

[Rong Chen]

Thanks, Sebastian!

yes, I also look forward to the new AOM/XML binding component.

Cheers,
Rong

On 6 September 2011 15:45, Sebastian Garde 
sebastian.garde at oceaninformatics.com wrote:

  Hi,

 I have modified the XMLSerialiser code and checked it in, you can compile
 it from there if you like.
 This will become part of the next minor release for ckm.

 Seref: looking forward to the binding!

 Cheers
 Sebastian

 Am 06.09.2011 11:44, schrieb Seref Arikan:

 Hi Rong,
 I'm working on this; an AOM to JAXB binding. I'm hoping that I'll be
 able to give more details in a couple of weeks.

 Regards
 Seref


 On Tue, Sep 6, 2011 at 10:34 AM, Rong Chen rong.acode at gmail.com 
 rong.acode at gmail.com wrote:

  Hi Sebastian,
 To my knowledge, no one is maintaining the AOM xml-serialiser from the Java
 Reference Project at the moment. So I would appreciate if you could fix it
 this time.
 Actually the larger issue about xml-serialiser is that it's not relying on a
 java XML binding API. This makes it vulnarable to changes in the archetype
 XML schema.
 There is already a xml-binding component that provides XML parsing and
 serialising based on RM XML schema. One just needs to implement a mapping
 between the classes from  openehr-aom component and the generated XML
 binding classes in order to have XML schema based parsing and serialising.
 This is probably the best way to go.
 Cheers,
 Rong
 On 6 September 2011 10:53, Sebastian Gardesebastian.garde at 
 oceaninformatics.com sebastian.garde at oceaninformatics.com wrote:

  Hi

 CKM is using the XML serialiser of the openEHR Java Reference
 implementation.

 It seems that the serialiser applies a different order to some elements
 than required by the schema.

 Not sure if these were turned around in the xsd at some stage maybe?
 While I don't really understand why these elements need to have an
 order, I believe the problem in the XML serialiser is quite easy to fix.

 Is anybody maintaining this code at present? Otherwise I can have a go.

 Regards
 Sebastian


 Am 05.09.2011 19:28, schrieb Athanasios Anastasiou:

  Hello everyone

 Maybe there has been some intermediate change that i am missing here but
 i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml
 (downloaded as XML from the CKM editor today) through the available XSDs
 from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and
 i am getting a very large number of errors.

 Just as an indication, all the errors are Invalid content was found
 mostly for the elements existence and lower_included (expecting
 rm_attribute_name and lower_unbounded respectively)

 Are there different XSDs for the structure of the CKM XML files? And if
 yes, are they available?

 Looking forward to hearing from you
 Athanasios Anastasiou

 P.S. Just as a note, Resource.xsd references basetypes.xsd instead
 of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was
 BaseTypes.xsd in version 1.0). It seems that the intention is to
 preserve the letter case (e.g. the Resource.xsd and Structure.xsd
 reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes
 a difference for case sensitive file systems :-)



 ___
 openEHR-technical mailing listopenEHR-technical at 
 openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

  ___
 openEHR-technical mailing listopenEHR-technical at 
 openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

  ___
 openEHR-technical mailing listopenEHR-technical at 
 openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

  ___
 openEHR-technical mailing listopenEHR-technical at 
 openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 --

[image: Ocean Informatics]
 Dr Sebastian Garde
 Senior Developer
 Ocean Informatics
*Dr. sc. hum., Dipl.-Inform. Med, FACHI*

 Skype: gardeseb

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/89cd6c41/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: oceanlogo.png
Type: image/png
Size: 5677 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/89cd6c41/attachment.png

New Version of the Clinical Knowledge Manager (CKM)

[Sebastian Garde]

Dear all,

We have released a new version (1.1.4) of the Clinical Knowledge Manager 
(CKM) at http://www.openehr.org/knowledge

This release includes new functionality, but also a lot of fine-tuning 
at many places:

  * Total rework of *Release Sets *
  o If you want email updates for new or updated release sets, check
the appropriate checkboxes in your options
  o Release Set now include templates, archetypes, and terminology
subsets. Validation ensures that the archetypes used by a
template are included in their proper revision. Release Sets can
also contain sub release sets.
  * A *Reference Model Description* has been added for major classes and
datatypes. This can be viewed for example, when clicking on the
little arrow next to a datatype within the view of an archetype. For
many archetypes, there is also a new reference model tab explaining
important additional attributes.
  * Archetypes, Reviews, Review Feedback can now be *printed*. To print
an archetype, open it in the Tabbed View and click on the Printable
version button. To print a review, simply right click on the
completed review in your dashboard and select Printable version.
  * Full support for*IE9*, Firefox 5, etc
  * All emails are now sent from one central address (with reply-tos
etc. set appropriately; i.e. the proper way to handle this in the
times of more and more spam and spam prevention)
  * *General discussion forum* for discussion not related to a
particular resource (Available as a top level menu item General
Discussion)
  * Resource *documentation *is now *versionable *if required. Resource
documentation can also be linked directly now for use in e.g. emails
via a *direct link*.
  * It is now possible to upload *two local archetypes* and compare
these two archetypes directly
  * Some *icon rework* (you may need to *empty your browser cache* to
see some of them)
  * And many more, including changes to display of archetypes, CKM's
ontology, and the review process, see the detailed list of changes
at: http://www.openehr.org/wiki/display/healthmod/CKM+release+1.1.4

If you have any problems or suggestions, please let me know direclty or 
via the Report bug and Suggest new feature menu items within CKM's 
About menu (when logged in).

Best regards
Sebastian
-- 
Ocean Informatics   
Dr Sebastian Garde
Senior Developer
Ocean Informatics

/Dr. sc. hum., Dipl.-Inform. Med, FACHI/

Skype: gardeseb

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110719/426e7f5f/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: oceanlogo.png
Type: image/png
Size: 5677 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110719/426e7f5f/attachment.png

CKM progress and RE: Archetype versioning on CKM

[Heather Leslie]

Hi Erik, Thomas,

 

I think we need to address three issues separately here. The first is the
archetype identification in CKM; the second is use of the draft archetypes
and the third, the apparent lack of progress of archetype publication in the
openEHR CKM.

 

Archetype identification is ultimately a technical issue and one in which I
normally don't have an opinion. Clearly it is useful from an implementation
point of view to have unique IDs for each archetype and be able to determine
diffs etc. However, from a non-technical point of view I believe that it is
extremely helpful to clearly delineate between early/alpha/raw models and
the mature ones that have been published, more than just by a 'status' or
icon, although we need these too. 

 

I'm increasingly of the opinion that it will be helpful to have a common
understanding that the first published version of an archetype in CKM is
always known as v1.0, such that if we eventually find we are using v4.x we
(the non-technical) can easily infer that this is a published archetype that
has undergone 3 major updates. This is very valuable to the non-techies who
will be using CKM. Otherwise we run the risk of having a release set that
will contain wildly disparate version numbers and will infer no idea of the
state/maturity of the archetypes

To be honest, how we version the pre-published, currently known as 'draft'
archetypes doesn't worry me - v0.x seems sensible in light of the previous
statements but if you have a better way to approach it, I'm cool with that.

 

Second point: use of the draft archetypes is an increasing issue. My general
rule of thumb is 'don't' - because they are likely to change significantly
by the time they are published. Do a diff on any of the published archetypes
in CKM eg Blood Pressure - this is available by clicking on the 'Archetype
History' icon on the toolbar in CKM  . Check the 'Compare' box for the
latest version of the archetype (on the left) and the first version (on the
right); Select 'Compare archetypes' up the top. I think you will be
surprised at the amount of change.

So if anyone wants to use them, do so, but understanding the implications.
In addition, further work in other domains has meant that modelling practice
has matured and when we are able to revise these archetypes we might
approach some quite differently. Draft is draft - please don't infer
anything more from them.

 

And this leads in to my related third point - the apparent lack of progress
on the openEHR CKM re archetype publication. To me it is the proverbial
'elephant in the room'. I am somewhat embarrassed, but we have not been
resourced to be able to continue this work directly in the volunteer openEHR
space. The Ocean team did a lot of huge amount of work in the early days to
get CKM up and running - Sam, Ian and Sebastian in particular - please don't
underestimate it. That burned me out, and I had to cut back; now paid work
has become busier - I have had to prioritise just like everyone else.

 

I would love to see the openEHR CKM flourishing but the Foundation and the
community needs to take it on and resource it, not just rely on Ocean
resources to drive it or do the actual work. The Editorial resources are
largely the bottleneck. It does take a particular personality and mindset,
attention to detail and a considerable time commitment to become an Editor.
Ian McNicoll and I took these roles on originally - we were learning and
needed to establish some processes. This is still being fine-tuned but we
are certainly in a position to mentor and train others who might be
interested in taking on some Editorial responsibilities and have the time to
do the job properly - it is never done in isolation, and the Editorial team
approach is proving very successful. I have approached some individuals who
I have thought might be suited but unfortunately most have baulked at the
potential time commitment. We have had one Editor start but they have
drifted off with other priorities. So we are absolutely open to more efforts
and probably should have been making this more public for some time now.

 

And the modelling efforts have not disappeared totally. There is active
modelling and reviewing of archetypes happening in the Australian NEHTA CKM
http://dcm.nehta.org.au/ckm/ . Many of the archetypes in here have been
drawn from the openEHR CKM and are now undergoing review and fine-tuning by
stakeholders in Australia. NEHTA's approach to development of a clinical
model library and publication of their specifications are found here
http://www.nehta.gov.au/connecting-australia/terminology-and-information/de
tailed-clinical-models . As we undertook this work with NEHTA we understood
that the models published in their CKM would be able to be shared back to
the international community - we are seeking confirmation of this, and hope
to be able to update the openEHR models with these more mature ones soon.
They are making good progress.

 

Ultimately we need

Archetype versioning on CKM

[Thomas Beale]

Erik,
thanks for the pointer. I like this set of rules. It is not too 
different from the current draft identification spec 
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf,
 
and it would be easy to upgrade it to reflect the SemVer rules more 
faithfully. In the openEHR spec, major.minor.patch is referred to as 
version.revision.build. I seem to remember a discussion where we thought 
about renaming these. Do people think we should just stop mentioning 
version/revision/build with respect to archetypes? Or is it helpful to 
think of an openEHR 'revision' as being the same as a 'minor' version 
(personally I think yes)?

The only thing I don't like that much is going back to putting 'draft' 
etc on the end of the version string, but I guess it is so common, that 
we should just go with the flow.

If we can get a bit of consensus here, I can update this draft proposal 
to reflect it pretty quickly.

- t

On 14/06/2011 09:24, Erik Sundvall wrote:
 Hi!

 I came to think of this openEHR versioning discussion thread when I
 read about the Semantic Versioning initiative at http://semver.org/

 I think the reasoning there is very appropriate also for openEHR artifacts.

 The problem for openEHR might be that there are so many seemingly
 usable archetypes in the openEHR-hosted CKM that are neither modified
 for a long time nor officially tagged as published. It is
 understandable if it's tempting to start using them in real systems
 already now. After all the alternative is to reinvent the wheel
 locally and is that really better? Perhaps there should be a time
 limit on how long artifacts in the CKM can stay at a version below
 1.0.0?

 Perhaps things would become easier if we break the link between an
 artifact having published status (as in being CRB approved) and the
 fact that an artifact has a version over 1.0.0. That way systems can
 start using archetypes past 1.0.0 knowing that non-compatible changes
 will have new major version numbers (irrespective of if they are
 published or not).

 Keeping approval badges like ARB published, NHS approved or WHO
 2011 Certified separate from technical version numbers might be a
 good idea anyway... (Example: the first ARB published version of
 Archetype X might be 2.4.2 and the next time it's awarded an ARB
 published badge again might be when the ARB has time to get around to
 looking at version 2.8.4 or 7.8.9). Likely, agencies will want to
 approve sets of artifacts on a regular basis like tagging a number of
 mutually compatible archetypes and templates as NHS 2012-Q1
 approved.

 The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1
 1.0.0beta2  1.0.0.) might solve the draft problem discussed in this
 openEHR thread previously. (Provided that beta versions etc. don't get
 used/abused in live EHR systems.)

 The Semantic Versioning specification formalism is also machine
 processable in a nice way.

 Best regards,
 Erik Sundvall
 erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733



 On Thu, Apr 28, 2011 at 13:41, Thomas Beale
 thomas.beale at oceaninformatics.com  wrote:
 On 28/04/2011 02:07, Heather Leslie wrote:

 Hi everyone,

 I think you are missing some of the further complexity here. There is a
 definite need for differentiation between draft and published archetypes for
 which a version number alone is not enough.
 Currently we are talking only about v1 archetypes and how to manage them,
 and to a degree it makes sense. We certainly considered using v0.x for
 drafts but it doesn't solve the downstream problems - once a v1 archetype is
 published, the non-breaking revisions will become v1.1, 1.2 etc. No problem
 But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but
 it needs to be clear that it is v2 *draft* initially and not v2 *published*
 until we have completed the neccessary collaborative reviews.

 There are two ways to look at this:

 A - 'draft' is only possible at the notional v0 or first version stage;
 after initial publication, it can't be used, since the archetype is now 'in
 the open'
 B - it is possible to go back to 'draft' status when the major version
 number is incremented on the basis that a new major version is a new
 archetype, and authors need to be able to go back into 'initial development'
 mode

 I can see arguments for both. What we need to decide on as a community is
 what rule we want here, and to stick to it. If we can decide that, we can
 document it and post it in a new draft of the identification specification.

 Diego's problem of knowing what archetype one is actually using is real and
 needs to be solved. CKM does track revision numbers, but they are not part
 of the version id, and you have to go into the revision history view to see
 them. However the above-mentioned identification draft spec indicates a
 system of referencing to do this such that an archetype whose id is
 currently shown as openEHR-EHR