Re: Seeking clarification regarding Assumed value

[Peter Gummer]

> On 8 Oct 2018, at 23:09, Peter Gummer  wrote:
> 
> ...Attached to this email is the CLUSTER that Ian attached to the Jira issue.

Hmmm, I don’t think this mailing list accepts attachments. Here is the CLUSTER 
as ADL.

Peter


archetype (adl_version=1.4)
openEHR-EHR-CLUSTER.ambient_oxygen.v1

concept
[at]-- Ambient oxygen
language
original_language = <[ISO_639-1::en]>
translations = <
["de"] = <
language = <[ISO_639-1::de]>
author = <
["organisation"] = <"University of Heidelberg, 
Central Queensland University">
["name"] = <"Jasmin Buck, Sebastian Garde">
>
>
>
description
original_author = <
["name"] = <"Ian McNicoll">
["organisation"] = <"Ocean Informatics">
["email"] = <"ian.mcnic...@oceaninformatics.com">
["date"] = <"08/06/2009">
>
details = <
["en"] = <
language = <[ISO_639-1::en]>
purpose = <"To record the amount of oxygen being 
delivered to the subject at the time of observation.  Assumed values of 21% O2, 
Fi02 of 0.21 and Oxygen flow rate of zero.">
use = <"May be used within an ACTION archetype to 
specificy oxygen therapy , or within OBSERVATION archetypes such as Blood gases 
or Respirations, as part of patient state, where knowledge of ambient oxygen 
status is critical to interpretation of the observation. 


">
keywords = <"breathing", "oxygen">
misuse = <"">
copyright = <"copyright (c) 2009 openEHR Foundation">
>
>
lifecycle_state = <"AuthorDraft">
other_contributors = <"Heather Leslie Ocean Informatics", "Sebastian 
Garde Ocean Informatics", "Andrew James University of Toronto", "Sundarasan 
Jaganathan NHS Scotland", "Omer Hotomargolu Turkey", "Marja Buur Medisch 
Centrum Alkmaar Netherlands", "Gregory Caulton PatientOS Inc.", "Anne Harbison 
CPCER", "Sam Heard Ocean Informatics">
other_details = <
["references"] = <"">
["MD5-CAM-1.0.1"] = <"1FCF286B5D47164C5D89907DF332BC65">
>

definition
CLUSTER[at] matches {   -- Ambient oxygen
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0051] occurrences matches {0..1} matches {
-- Oxygen flow rate
value matches {
C_DV_QUANTITY <
property = <[openehr::126]>
list = <
["1"] = <
units = <"l/m">
magnitude = 
<|0.0..50.0|>
precision = 
<|1|>
>
["2"] = <
units = 
<"ml/min">
magnitude = 
<|0.0..5.0|>
precision = 
<|1|>
>
>
assumed_value = <
magnitude = <0.0>
units = <"l/m">
precision = <1>
>
>
}
}
ELEMENT[at0052] occurrences matches {0..1} matches {
-- FiO2
value matches {
DV_PROPORTION matches {
  

Re: Seeking clarification regarding Assumed value

[Peter Gummer]

Hi Heather,I think I've tracked down why this was changed in the Ocean Archetype Editor. It seems to be this change on 6th May 2012:	https://github.com/openEHR/arch_ed-dotnet/commit/bb50d16ad44e910d717c9e75e967fe1b1af36c46	EDT-567: Allow assumed value to be set on any data, not just on patient state, for DV_TEXT and DV_BOOLEAN.It was our good friend Ian McNicoll who raised this change request ... on 30th Jul 2009. (My, how the years do pass!) Ian marked the priority as major (though it took me a few years to get around to “fixing” it). Here’s what Ian wrote in Jira:'Assumed value' can only be entered via Patient State - needs to be available throughoutDescriptionThe option to enter an assumed value only appears when a data element is being added within patient state. As far as I can tell this is a local implementation issue and not a requirement of the AOM.We are increasingly making use of CLUSTER archetypes such as Ambient_oxygen.v1 which, of course, have no state attribute, but which depend on having assumed values for some elements, in this case the flow rates and oxygen proportions.I have logged this as major since Ambient_oxygen is an openEHR CKM archetype on which a number of other soon to be published OBSERVATIONS will depend.Attached to this email is the CLUSTER that Ian attached to the Jira issue.

openEHR-EHR-CLUSTER.ambient_oxygen.v1.adl
Description: Binary data
Hope that helps. Let the debate begin!Cheers,PeterOn 8 Oct 2018, at 21:16, Heather Leslie  wrote:Hi everyone, Assumed value - https://www.openehr.org/releases/AM/latest/docs/AOM1.4/AOM1.4.html#_assumed_value I’ve spoken to Sam Heard on many occasions and I have understood him to say that the intent for an assumed value to only be relevant for ‘State’ in an OBSERVATION. But never in ‘Data’. This is what I’ve always taught modellers. The original Ocean Archetype Editor, had this implemented. In more recent years ‘assumed value’ was implemented across all of the parts of the OBSERVATION. Incorrectly, as I understand it, but the code was never reviewed nor updated. We are now debating how this should be implemented in the new ADL Designer, and I’m seeking clarification. It makes sense to be able to potentially have an assumed value for ‘State’ – for example the position of the patient if it is always the same in 99% of use cases. The theory, as I understand it, is that in this situation the position will only be recorded if the assumed value is modified from the assumed value. (Mind you, if the assumed value is excluded/zero occurrence in an implemented template, it will not necessarily be a valid assumption, but let’s keep that argument about whether assumed values are reasonable at all for later).  The discussion is often further compounded by confusion about default vs assumed values. I don’t think that it makes any sense to allow an ‘assumed value’ for actual data values eg a Systolic Blood Pressure measurement – especially if, as per the specs link (above), “The notion of assumed values is distinct from that of 'default values'. The latter is a local requirement, and as such is stated in templates; default values do appear in data, while assumed values don’t.” My question to the list: Data values need to be recorded explicitly and should never be assumed – True or False? Thanks Heather___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Okay, interesting! It would have made things easier for us 5 or 10 years ago to 
have had a looser interpretation of the ‘unique path rule’. Perhaps it was a 
case of erring on the side of caution, since it's always easier to relax a rule 
that turns out to have been too strict rather than retrospectively tighten a 
rule that was too lax.

This would have implications for operational templates, as well as for existing 
downstream software that consumes the OPTs. Would OPTs generated by the new ADL 
Designer tool fail validation by existing software?

I’m looking forward to a more detailed explanation, if someone knows.

Thanks Hildi,
Peter


> On 20 Aug 2018, at 20:49, Hildegard McNicoll  wrote:
> 
> Hi Peter
> 
> It's probably best to defer the exact answer to others, but my understanding 
> is that the 'unique path rule' was interpreted too tightly in Template 
> Designer, rather than this being a strict limitation in ADL 1.4. Certainly 
> there is no need to migrate to ADL 2.0 with ADL Designer, it handles ADL 1.4 
> perfectly well.
> 
> But as I said - other people may want to pitch in and provide a more detailed 
> explanation.
> 
> Kind regards
> 
> Hildi
> 
> Hildegard McNicoll
> Chief Operations Officer
> 
> 
> 
> mobile:  +44 (0)7932 502655
> landline:  +44 (0)1536 414994
> skype: hild5559
> twitter: @hildegardfranke
> LinkedIn <http://www.linkedin.com/in/hildegardfranke>
> 
> On Mon, 20 Aug 2018 at 11:42, Peter Gummer  <mailto:peter.gum...@gmail.com>> wrote:
> Hi Hildi,
> 
>> On 20 Aug 2018, at 19:13, Hildegard McNicoll > <mailto:hi...@freshehr.com>> wrote:
>> 
>> Incidentally, the new web based ADL Designer tool developed by Marand 
>> doesn't have this problem anymore. As far as I know it is very close to 
>> being released now.
> 
> 
> I’m curious — from a purely academic perspective, now, since unfortunately 
> I’ve not been able to participate in the openEHR revolution for the last 
> couple of years — how this new tool is able to do that. Does this require 
> migrating to ADL 2.0? As I recall (and it could be my memory at fault here) 
> this was a limitation of ADL 1.4, rather than of the Ocean Template Designer 
> itself.
> 
> Peter

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

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Hi Hildi,

> On 20 Aug 2018, at 19:13, Hildegard McNicoll  wrote:
> 
> Incidentally, the new web based ADL Designer tool developed by Marand doesn't 
> have this problem anymore. As far as I know it is very close to being 
> released now.


I’m curious — from a purely academic perspective, now, since unfortunately I’ve 
not been able to participate in the openEHR revolution for the last couple of 
years — how this new tool is able to do that. Does this require migrating to 
ADL 2.0? As I recall (and it could be my memory at fault here) this was a 
limitation of ADL 1.4, rather than of the Ocean Template Designer itself.

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

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Hi Dileep,

Right-click the node and select the Clone option. Then rename the duplicate of 
the node. 

Regards,
Peter 


> On 20 Aug 2018, at 15:03, Dileep V S  wrote:
> 
> Dear Peter,
> 
> Thanks for your reply. However I am not sure I fully understand the logic of 
> this. 
> 
> OpenEHR has a way to represent multi occurrence nodes (by appending 0, 1 etc 
> to the path) such that the paths will remain unique. This should work even 
> when the mode is constrained with a name as well. May be I am missing 
> something here.
> 
> I am not sure what you mean by cloning the node? Can this be done in Template 
> designer? if yes how
> 
> regards
> 
> 
> 
> 
> Dileep V S
> Founder
> HealtheLife Ventures LLP
> m:+91 9632888113
> a:106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w:healthelife.in  e: dil...@healthelife.in
> 
>> On Sun, Aug 19, 2018 at 5:46 PM, Peter Gummer  wrote:
>> Hi Dileep,
>> 
>> Yes, this is expected. The behaviour was first noticed about 10 years ago, 
>> and initially it was reported as a bug. After some thought we realised that 
>> it’s the correct behaviour. I found it incredibly annoying too!
>> 
>> My memory of the exact reasoning is poor, after all of these years; but I 
>> think it’s something like this:
>> 
>> Initially, the name of the archetype node is unconstrained. As a 
>> consequence, any name would be valid for this node. Therefore, there’s an 
>> unlimited number of unique paths to the data that could be stored at this 
>> node’s path: for example, at1234[name = “a”], at1234[name = “b”], 
>> at1234[name = “c”], etc.
>> In the template, when you constrain the archetype node to a single specific 
>> name, there is only one possible path to the the node: for example, 
>> at1234[name=“whatever name you’ve constrained it to”]. There’s only one 
>> possible unique path to this. Therefore, the maximum  occurrences possible 
>> is 1.
>> 
>> Essentially, this arises because there has to be one unique path to each 
>> node in the data. This is important so that each data node can be identified 
>> unambiguously within the EHR.
>> 
>> There is a workaround, however. (But again, my memory may be inaccurate, so 
>> please forgive me if this isn’t quite right or complete.) To allow multiple 
>> occurrences, you need to clone the node. Then you can rename the clone. 
>> Although the renamed clone will be single-occurrence, this will retain the 
>> original node as multiple occurrences. Or at least I think this is how it 
>> works — it’s been quite a few years!
>> 
>> I have an even vaguer recollection that ADL 2.0 may have resolved this in a 
>> more satisfactory way. Perhaps Thomas or someone can elucidate.
>> 
>> Hope this helps,
>> Peter
>> 
>> 
>>> On 19 Aug 2018, at 20:24, Dileep V S  wrote:
>>> 
>>> Hi,
>>> 
>>> I am observing a strange behavior in the template designer and whated to 
>>> check if this is the expected behavior and if not how to manage it.
>>> 
>>> In any template, when ever I rename any archetypes, their occurrence gets 
>>> set to [0..1] automatically (single occurrence). The options for selecting 
>>> multiple occurrences is no more available.
>>> 
>>> Have anybody else noticed this problem? Is there any way to work around 
>>> this as some of these archetypes need to be multiple occurrences
>>> 
>>> Please see screenshots attached for reference
>>> 
>>> regards
>> 
>> 
>> ___
>> 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: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Hi Dileep,

Yes, this is expected. The behaviour was first noticed about 10 years ago, and 
initially it was reported as a bug. After some thought we realised that it’s 
the correct behaviour. I found it incredibly annoying too!

My memory of the exact reasoning is poor, after all of these years; but I think 
it’s something like this:

Initially, the name of the archetype node is unconstrained. As a consequence, 
any name would be valid for this node. Therefore, there’s an unlimited number 
of unique paths to the data that could be stored at this node’s path: for 
example, at1234[name = “a”], at1234[name = “b”], at1234[name = “c”], etc.
In the template, when you constrain the archetype node to a single specific 
name, there is only one possible path to the the node: for example, 
at1234[name=“whatever name you’ve constrained it to”]. There’s only one 
possible unique path to this. Therefore, the maximum  occurrences possible is 1.

Essentially, this arises because there has to be one unique path to each node 
in the data. This is important so that each data node can be identified 
unambiguously within the EHR.

There is a workaround, however. (But again, my memory may be inaccurate, so 
please forgive me if this isn’t quite right or complete.) To allow multiple 
occurrences, you need to clone the node. Then you can rename the clone. 
Although the renamed clone will be single-occurrence, this will retain the 
original node as multiple occurrences. Or at least I think this is how it works 
— it’s been quite a few years!

I have an even vaguer recollection that ADL 2.0 may have resolved this in a 
more satisfactory way. Perhaps Thomas or someone can elucidate.

Hope this helps,
Peter


> On 19 Aug 2018, at 20:24, Dileep V S  wrote:
> 
> Hi,
> 
> I am observing a strange behavior in the template designer and whated to 
> check if this is the expected behavior and if not how to manage it.
> 
> In any template, when ever I rename any archetypes, their occurrence gets set 
> to [0..1] automatically (single occurrence). The options for selecting 
> multiple occurrences is no more available.
> 
> Have anybody else noticed this problem? Is there any way to work around this 
> as some of these archetypes need to be multiple occurrences
> 
> Please see screenshots attached for reference
> 
> regards

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

Re: Announcing Archie version 0.4

[Peter Gummer]

Interaction with a JavaScript front-end could be done with any back-end 
programming language — it doesn’t have to be Java.

So your point is that Archie's serialisation and deserialisation to JSON will 
will assist this? I believe Thomas’s Eiffel implementation already has JSON 
serialisation, since about 5 years ago.

Peter


> On 3 Feb 2018, at 23:03, Pieter Bos <pieter@nedap.com> wrote:
> 
> Or a Java app with rest api and a JavaScript frontend. Let the java 
> application take care of parsing, validating, flattening, operational 
> template creation etc and send json to your front end. Archie has built-in 
> json serialization and deserialization support.
> 
> Pieter
> 
> Op 3 feb. 2018 om 12:05 heeft Seref Arikan 
> <serefari...@kurumsalteknoloji.com<mailto:serefari...@kurumsalteknoloji.com>> 
> het volgende geschreven:
> 
> Hi Peter,
> 
> Presumably via use of a transpiler or a bytecode to js/webassembly compiler.
> 
> On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer 
> <peter.gum...@gmail.com<mailto:peter.gum...@gmail.com>> wrote:
> On 1 Feb 2018, at 05:13, Thomas Beale 
> <thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:
> 
> ... But the main interest is that we will be able to build new tools such as 
> a Java/JS replacement for the ADL Workbench, and of course things like a 
> high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
> workflow implementations and many other components.
> 
> Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how 
> Archie (written in Java, disappointingly) would enable JavaScript 
> implementations. JavaScript has nothing in common with Java (apart from the 
> name).
> 
> Peter


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

Re: Announcing Archie version 0.4

[Peter Gummer]

On 1 Feb 2018, at 05:13, Thomas Beale  wrote:
> ... But the main interest is that we will be able to build new tools such as 
> a Java/JS replacement for the ADL Workbench, and of course things like a 
> high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
> workflow implementations and many other components.
> 

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter

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

Re: Problem with creating medication order with Template designer

[Peter Gummer]

Hi Dileep,

According to the error message, the problem is with the timing_repetition 
archetype. The error says that it has an unexpected attribute: existence.

Your zip file doesn’t contain this archetype so I can’t take a look at it 
myself, but it should be easy to find the existence attribute.

Regards,
Peter


> On 19 Dec 2017, at 16:53, Dileep V S  wrote:
> 
> Hi,
> 
> I am trying to create a medication order template using Template designer and 
> am getting  an error while trying to add openEHR-EHR-CLUSTER.timing_daily.v0 
> and openEHR-EHR-CLUSTER.timing_repetition.v0. More details along with the 
> screenshot of the error in the attached file. I am also attaching the 
> template file set for reference.
>  
> I looked at the offending Archetypes, but could not find any problem. If any 
> of you have faced similar problems before, pls point me in the right 
> direction to find a solution.
> 
> Thanks in advance for your help

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

Re: Creating archetypes with alternatives

[Peter Gummer]

Hi Pablo,

The way to produce the ADL that you’ve posted below is with a “Choice” element.

1. Go to the Archetype Editor’s “Definition” tab.
2. Click the [+] button on the left.
3. From the drop-down list, select “New element” and “Choice”.
4. Over on the right of the screen, you will see two buttons, [+] and [-]. 
Click the [+] button and select “Text”.
5. Repeatedly click the [+] button to add all of the data types that will be 
permitted in this element.

Hope that helps,
Peter


> On 9 Feb 2017, at 10:52, Pablo Pazos  wrote:
> 
> Hi,
> 
> I'm testing the EHRServer with alternative datatypes for the same 
> ELEMENT.value. 
> 
> I found the only way of doing that in the Archetype Editor is by setting the 
> node as Any. And there is no way to further constraint the allowed datavalues 
> in the AE.
> 
> In the Template Designer I can further constraint that by specifying which 
> specific types can be used, to avoid the possibility of allowing any 
> datavalue to be there. The problem I found is that after setting the allowed 
> datavalues, I can't set constraints for them, e.g. if I specify Coded Text, I 
> can't set the code list.
> 
> Shouldn't the datatype constraints be set also on the AE and the constraints 
> per allowed datavalue allowed to be set on the AE and TD?
> 
> I've seen some ADLs/OPTs from Brazil with alternatives, and I don't know if 
> they are using another AE/TD or just setting the constraints by hand. For 
> example a problem status archetypes has this which I can't reproduce in the 
> Ocean's AE:
> 
> ELEMENT[at0082] occurrences matches {0..*} matches {-- 
> Unspecified
> value matches {
> DV_TEXT matches {*}
> DV_BOOLEAN matches {
> value matches {True, False}
> }
> DV_COUNT matches {*}
> }
> }
> 
> 
> Thanks!
> 


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

Re: Cloud EHRServer is about to be launched

[Peter Gummer]

There is in fact a mailing list dedicated to announcements: the 
openehr-announce list. It’s the first one listed here:
http://openehr.org/community/mailinglists

Peter


> On 27 Dec 2016, at 03:55, Bert Verhees  wrote:
> 
> I think Jan Marc has a point but Pablo is excused because there is no other 
> way inside the community
> Would be a good idea to have a list for announcements by the public. 
> 
> Best regards
> Bert Verhees 

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

Re: UCUM code in body temperature archetype

[Peter Gummer]

Hi Silje,

Yes, it was at the end of October that I was trying to get it to work. A 
DataGrid in AE was throwing exceptions, complaining about duplicates because 
the property_id and text fields have to form a unique key. I did manage to find 
and remove one pair of duplicates from the file that you provided but even 
after that it was still complaining. I never got to the bottom of what was 
causing it.

Looking at GitHub, nothing resembling your corrections appears to have made it 
there yet:


https://github.com/openEHR/arch_ed-dotnet/commits/master/ArchetypeEditor/PropertyUnits

I would suggest that the best way to proceed would be to add the fixes again, 
but proceed slowly, testing your file in AE after every few changes. Keep a 
backup copy after each successful test. Then, if AE complains about a small set 
of changes, it will be easy to identify what has caused it.

Peter


> On 18 May 2016, at 22:37, Bakke, Silje Ljosland 
>  wrote:
> 
> They usually are, though the units file in the Archetype Editor has had 
> (still has?) a lot of errors in it, which means the correct units had to be 
> edited into the ADL by hand. I made a better version of the units file for 
> the AE a while ago, but there were some issues with it that I'm not sure if 
> have been solved or if it's made its way into a release.
> 
> Regards,
> Silje


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

Re: Party-actor-folder relationships in hierarchy

[Peter Gummer]

On 27 Nov 2015, at 21:30, Bert Verhees  wrote:
> 
> Anyway, the Ocean Archetype-Editor (does it support demographics now?) is not 
> the OpenEHR specification, it is just an implementation.


Hi Bert,

No, the Ocean Archetype Editor doesn’t support demographics yet. Fixes and 
improvements to the EHR support have always been higher priority in the past, 
according to the tool's users.

Ian McNicoll did make some progress on demographic support a few years ago and 
he said it was looking like it wouldn’t be too difficult, but I guess other 
priorities must have intervened.

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

Re: Missing support for ISM_TRANSITION/transition in Archetype Editor and Template Designer

[Peter Gummer]

On 28 Nov 2015, at 00:36, Ivar Yrke  wrote:
> 
> Are there any plans to include transition support in these tools? Is there 
> anything we are overlooking in our approach?


Hi Ivar,

Until two years ago the Archetype Editor used to have a Transitions option from 
the Pathway Specification. It had never worked in any previous version of the 
Archetype Editor, however; and up until that time no one had ever found that 
the transition constraints should be limited more than the standard openEHR 
state diagram.

Pablo Pazos raised a problem report that alerted us to the fact that it wasn’t 
working:
https://openehr.atlassian.net/browse/AEPR-6

Pablo’s discussion about it on CKM is here (log in, click on the Discussion 
button, and expand the replies):
http://ckm.openehr.org/ckm/#showArchetype_1013.1.123

The partial implementation that was in place in the Archetype Editor until then 
seemed back-to-front with respect to the reference model: the RM specifies that 
ISM_TRANSITION.transition is the transition that occurred to arrive in the 
current state, whereas the user interface was constraining which states could 
be reached from the current state. To avoid confusion, we removed the 
non-functional implementation after Pablo reported it.

If people actually need to constrain transitions, then there is some work to do 
in the Archetype Editor. First of all, we would have to decide what the ADL and 
XML should look like. Pablo suggested that the ADL would be just a constraint 
of a DV_CODED_TEXT attribute (ISM_TRANSITION.transition), like the constraints 
on ISM_TRANSITION.current_state or ISM_TRANSITION.careflow_step.

Apart from the work in the Archetype Editor, it would affect downstream tools 
which would start to encounter constraints on ISM_TRANSITION.transition for the 
first time; and, as always when implementing something for the first time in 
archetypes, this entails a risk that those downstream tools might break. The 
Template Designer, OPT generation and CKM would all be likely to need fixes to 
support it.

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

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

[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

CRUD Restlet

[Peter Gummer]

Ralph van Etten wrote:

 This has lead to our current version of MedRecord (which is still work in 
 progress) and can be found here:
 
 https://mr.dev.medvision360.org/mr/apidocs/#!/


Hi Ralph,

That link doesn?t work. It displays this:

{error:406,message:The resource identified by the request is only capable 
of generating response entities which have content characteristics not 
acceptable according to the accept headers sent in the request,cause:user?}

- Peter

CRUD Restlet

[Peter Gummer]

Hi Ralph,

Mac OS X 10.9.5 with Safari 7.1.2.

The first time I clicked on the link it asked me for a certificate, which 
seemed pointless to give it for API docs so I clicked Cancel. Then it displayed 
the error.

On subsequent attempts it goes straight to the error. I guess the browser must 
be remembering my initial response.

I had been hoping to see how a RESTful web service could be easy to use, since 
in my experience they?ve always been at least an order of magnitude more 
difficult than SOAP, at least with .NET systems where basically you just enter 
the URL and click a few buttons and hey presto, you have a bunch of proxy 
classes that you can easily program against with full type-safety ? as opposed 
to hours or days of reading docs, which are probably inaccurate, and 
trial-and-error tearing your hair out with frustration to find simple typos or 
type errors, wondering how you?ve suddenly time-travelled back into the 1970s. 
But maybe there are nice technologies out there for consuming RESTful services 
easily that I?ve never encountered, so I was intrigued to learn.

I do like your description of the API of MediRecord, even if am sceptical about 
its ease of use ;-)

Peter


On 20 Jan 2015, at 0:01, Ralph van Etten ralph at medvision360.com wrote:

 Hi Peter,
 
  This has lead to our current version of MedRecord (which is still work in 
  progress) and can be found here:
 
 https://mr.dev.medvision360.org/mr/apidocs/#!/
 
 
 Hi Ralph,
 
 That link doesn?t work. It displays this:
 
 {error:406,message:The resource identified by the request is only 
 capable of generating response entities which have content characteristics 
 not acceptable according to the accept headers sent in the 
 request,cause:user?}
 
 I am sorry to hear that.
 Can you tell me what browser you are using and for which platform (Windows, 
 OSX, Linux)?
 
 Thanks,
 
 Ralph van Etten
 MedVision360

CRUD Restlet

[Peter Gummer]

Ralph van Etten wrote:

 Perhaps you can try the version without SSL?
 
 http://mr.dev.medvision360.org/mr/apidocs/#!/

Yes, Ralph, that version works for me.

Also, for the record, Ralph made the server less strict so that the original 
link that he gave us http://mr.dev.medvision360.org/mr/apidocs/#!/ also works 
for me now.


 I agree with what you are saying and using a REST API directly in a 
 application which is not a JavaScript application running in a web browser 
 can be a challenge.

Ah hah, that one sentence clarifies a lot! As so often is the case, it?s all 
about context.


 https://javadoc.medvision360.org/model-client-jee/latest/latest/index.html?nl/medrecord/model/client/procedure/oq45/Oq45Resource.html

I have the same SSL certificate problem here. It won?t let me in.


 BTW. for consuming REST APIs you should check out http://swagger.io/
 It can generate those proxy classes for you. It is not what we are currently 
 using because our solution predates swagger but I am considering upgrading :)

Now this looks interesting, especially the bit that says, almost every modern 
programming language and deployment environment.?

Peter

CRUD Restlet

[Peter Gummer]

Bert Verhees wrote:

The point for me is separation of transport layer and application layer, and 
each domain has its own errorhandling.


Hi Bert,

HTTP is not a transport layer protocol:

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

?The Hypertext Transfer Protocol (HTTP) is an application 
protocolhttp://en.wikipedia.org/wiki/Application_protocol ?

Thanks for the discussion, though. I?ve learned a lot from it.

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

XSL transform files for other languages?

[Peter Gummer]

Bakke, Silje Ljosland silje.ljosland.bakke at 
helse-bergen.nomailto:silje.ljosland.bakke at helse-bergen.no wrote:

Are there any alternative XSL transform files like tdo-csharp.xsl but for other 
languages available anywhere? Specifically, a VB.nethttp://VB.net one would 
be very useful.


Hi Silje,

I?m not aware of TDO transforms for languages other than C#.

But if you want to use TDOs in VB.NEThttp://VB.NET (or in any other .NET 
language), you could simply use the C# TDOs. Your VB.NEThttp://VB.NET 
application should be able to use the C# classes just as easily.

Regards,
Peter
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141106/ea8301b2/attachment.html

Ocean Template Designer crashes

[Peter Gummer]

pablo pazos pazospablo at hotmail.commailto:pazospablo at hotmail.com wrote:

The version I have is 2.6.1214Beta, don't know if that's the last revision of 
the 2.6 version.

That?s interesting, the latest 2.6 version that we have is 2.6.1213. Our 
downloads server crashed here last year and maybe we lost a version.


One issue I had, not related to crashes, is the difficulty to select the 
language for the template/OPT, I couldn't find where I can specify the 
language. It seems TD is detecting my environment language (es), but don't know 
how to change it e.g. for english.

You can use the /l: command-line switch. For example, to select Spanish, you 
could edit your Template Designer shortcut:

C:\Program Files (x86)\Ocean Informatics\Template 
Designer\TemplateDesigner.exe /l:es-UY

You have to specify a culture-specific language, i.e. you must include the 
country. Once you?ve done this, you will see the language code in Template 
Designer's title bar.

The Archetype Editor has had much the same capability for the last couple of 
years too.

Peter
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140606/1e5f2011/attachment.html

Ocean Template Designer crashes

[Peter Gummer]

Hi Pablo,

Archetype Editor's menu option to change to a different language is different 
from the command-line option:

* The command line option overrides your computer?s locale. For example, when 
in England, your computer's locale is probably en-GB and the user interface 
will be displayed in English. Archetypes will also display the en-GB 
terminology, if available, falling back to the neutral ?en? if need be. If you 
specify the es-UY command-line option, however, the user interface will be 
displayed in Spanish and archetypes will display the Spanish terminology, if 
available.

* The menu option to change to a different language does not affect the 
language that the user interface is displayed in. It only chooses which 
language the current archetype is displayed in.

Template Designer can do the former, but to the best of my knowledge it cannot 
do the latter. So I guess what you?re asking for is the ability to use Template 
Designer in one language but to choose a different language for the template.

In the meantime, you can use the command-line /l: option. Like the Archetype 
Editor command-line option, it changes the whole user interface, including the 
template and archetype terminology. It also changes the OPT export language. 
Yes, this is a very inconvenient way to view a template in a different 
language, especially if you don?t know how to read the language that you?ve 
selected!

Peter


On 6 Jun 2014, at 15:01, pablo pazos pazospablo at 
hotmail.commailto:pazospablo at hotmail.com wrote:

I just double checked, yes that's my version (rev 1214) :)

The difference with the AE is that has a locale change using the menu on the 
UI, will try the command line for the TD, but I think doing this from the UI is 
simplest. Maybe that can be a nice feature to request (?)

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos


From: peter.gummer at 
oceaninformatics.commailto:peter.gum...@oceaninformatics.com
To: openehr-technical at lists.openehr.orgmailto:openehr-technical at 
lists.openehr.org
Subject: Re: Ocean Template Designer crashes
Date: Fri, 6 Jun 2014 04:30:44 +

pablo pazos pazospablo at hotmail.commailto:pazospablo at hotmail.com wrote:

The version I have is 2.6.1214Beta, don't know if that's the last revision of 
the 2.6 version.

That?s interesting, the latest 2.6 version that we have is 2.6.1213. Our 
downloads server crashed here last year and maybe we lost a version.


One issue I had, not related to crashes, is the difficulty to select the 
language for the template/OPT, I couldn't find where I can specify the 
language. It seems TD is detecting my environment language (es), but don't know 
how to change it e.g. for english.

You can use the /l: command-line switch. For example, to select Spanish, you 
could edit your Template Designer shortcut:

C:\Program Files (x86)\Ocean Informatics\Template 
Designer\TemplateDesigner.exe /l:es-UY

You have to specify a culture-specific language, i.e. you must include the 
country. Once you?ve done this, you will see the language code in Template 
Designer's title bar.

The Archetype Editor has had much the same capability for the last couple of 
years too.

Peter

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

Archetype Editor Language/terminology related problems

[Peter Gummer]

 This is not related to the topic, but I prefer to have all this reports on th 
 same thread. When I create an archetype (see attached), without saving it, 
 and click on the interface tab (i spanish should be interfaz), I get an 
 exception:
 
 ...
 System.NotSupportedException: Constraint type 'Parsable' not supported as a 
 view.


Thanks, Pablo, can you raise that one too when you get a chance? We should 
catch the exception or, better, implement Parsable on the Interface tab.

I?ll try to remember to add the ?Interfaz? translation too. It?s just a matter 
of adding the necessary ?es? entry to AE's Terminology.xml file.

Peter

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

Archetype Editor Language/terminology related problems

[Peter Gummer]

pablo pazos pazospablo at hotmail.com wrote:

 About translations, I would like to create poper translations to spanish. Is 
 there a translation guide or i18n files I can upgrade?


Hi Pablo,

All of Archetype Editor?s translations are in one file, ?terminology.xml? which 
is maintained on GitHub:


https://github.com/openEHR/arch_ed-dotnet/tree/master/ArchetypeEditor/Terminology

It looks like you already have a GitHub account (ppazos), so Thomas will set 
you up so that you can clone the arch_ed-dotnet repository, make your changes 
to ?terminology.xml? and then push them back up.

You can edit the raw XML if you wish (it?s a pretty simple file), or there?s an 
exe in the same folder that you can use instead, purpose-built for doing these 
translations.

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

Archetype Editor Language/terminology related problems

[Peter Gummer]

pablo pazos pazospablo at hotmail.com wrote:

 1. When I add and remove EVENTs from an OBSERVATION, and then go to the 
 Terminology tab, I can see all the nodeIDs generated for the EVENTs I've 
 created but already removed from the archetype definition. Screen capture 
 shows the items that should not be seen.


Archetype Editor doesn?t clean up unused ontology codes until you save the 
archetype. I think if you save it, you?ll see that they are gone. Please raise 
a problem report if they are still there after you save.

I?ve always thought that this was by design, so that any text or description 
from a node that you had just deleted would still be available for you to copy 
to another node, if you wanted to do that. But I?m not sure ? it?s always been 
like that. Is the current behaviour good, or would it be better if the deleted 
codes were removed immediately?


 2. Adding a language and trying to toggle using the main men? or CTRL+L 
 doesn't work. If I change the language manually: Language  Change Language  
 ES, then CTRL+L and Language  Toggle Language start to work.


Yes that is a bug. The problem is only on the Terminology tab, and only with 
the Ctrl+L shortcut, right? Could you log the problem at 
http://www.openehr.org/issues/browse/AEPR please?

Thanks, Pablo. Good luck with the workshops.

- Peter

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

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Thomas Beale thomas.beale at oceaninformatics.com wrote:

 On 20/09/2013 12:01, Diego Bosc? wrote:
 ...
 There is even an invariant defined as Archetype_node_id_valid: 
 archetype_node_id /= Void and then not archetype_node_id.is_empty
 How does this work in your current implementations when sometimes the at 
 code is not present?
 
 it's simpler than you think - we made that property mandatory so that 
 programmers would never get a null exception. If it doesn't contain an 
 at-code or an archetype id, it can be empty (but not null), or (what the ADL 
 workbench currently does) - it can contain a dummy id like 'unknown' that the 
 software can easily spot and strip out.


I think it has to be the dummy id. According to the invariant, it can't be 
empty.

Peter

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

pablo pazos pazospablo at hotmail.com wrote:

 I would like to see both Archetype Editors to support this profile: to open 
 an archetype with the default behaviour of the specs (not having a nodeID for 
 every node) on LinkEHR Ed. and work ok, and open a profiled archetype in 
 Ocean AE and also work ok.
 
 Is that tough to do?


Never having seen a LinkEHR archetype myself, I can't say for sure how tough it 
would be to open one in the Ocean AE successfully and then make sure that the 
at-codes are preserved in the ADL and XML output, Pablo. I would guess that it 
would take a couple of days at least ? and then it would have to be tested to 
make sure that the enhancement didn't break any other functionality. I don't 
have a couple of days right now to spend on something that has no business case 
behind it.

But a good first step towards making such a business case would be if someone 
who needs this enhancement could find a few minutes to raise the issue on Jira 
? with an example :-)

Peter
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130902/805cafa7/attachment.html

Archetype Nodes

[Peter Gummer]

Bert Verhees bert.verhees at rosa.nl wrote:

 The items in ontology are very limited, only text and description. I must 
 agree that this is not much, especially if you want the at-nodes being 
 explained by code systems.
 But on the other hand, it is easy to introduce a sanity-rule. Let the text be 
 a code, and let the description be the indicator of the code-system involved.
 
 I must agree that it is not forced, thus weak. Better was to extend the 
 ontology with appropriate items. Do you think that would be a good idea?


Hi Bert,

It's true that the only attributes for each term in the ontology are its 
at-code, plus its text and description.  But this is not all that you can do 
with a term.

* You can bind at-codes to terminology codes, to define the meaning of a node 
in various terminologies.

* In ADL 1.5, you can add 'attributes' to a terms. These attributes are 
arbitrary code-value pairs. The openEHR Archetype Editor is still stuck on ADL 
1.4 so it doesn't support this yet, but it does provide pretty much the same 
functionality by allowing arbitrary keys other than code, text and 
description on the terms. This is a bit of a hack, but in the future when the 
archetypes using these non-standard term keys are converted to ADL 1.5, it 
should be a very straightforward process to move the non-standard keys 
automatically into the attributes section.

Peter

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Bert Verhees bert.verhees at rosa.nl wrote:

 The issue is that both, Ocean and LinkEhr, do not recognize their 
 responsibility and do not see a need to change this.


Hi Bert,

Glad you've brought this up again, but the problem won't get fixed unless you 
report it. Can you report the problem at 
http://www.openehr.org/issues/browse/AEPR and attach an archetype that 
demonstrates it?


 These problems exist for years now, everyone knows about them, If it was my 
 software, I would comfort my users and customers with friendly solutions.


If I had a problem that I wanted fixed, I would report it in the problem 
tracker.

We are very busy and working on other projects. If this problem is important to 
you, please report it and we may get around to it some day. Please make sure 
that you attach an example of an archetype that demonstrates the problem.

Peter

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Bert Verhees bert.verhees at rosa.nl wrote:

 Or leave it and do nothing with it, like this has been done for years now. 
 The market maybe will correct you.


Nothing has been done about it, Bert, because no one has ever logged it as an 
issue.

If any one out there actually does care about this, then please log it at 
http://www.openehr.org/issues/browse/AEPR with an example archetype. Problems 
logged there do get fixed.

Peter

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Bert Verhees bert.verhees at rosa.nl wrote:

 They could be grateful accept the help I offered until now and profit from 
 it, they can also do nothing with it. It is their choice. I fully respect 
 that.
 
 But saying that the tool isn't better because I (me, as a person) refuse to 
 walk through some time-consuming formalities, that is not right, is my 
 opinion.
 
 I leave it all up to the originators to improve their tooling or leave it as 
 it is.


Very happy to have the help, Bert. Without people like you reporting problems, 
we don't know about them.

Look forward to getting that problem report when you get a chance. It should 
only take you a couple of minutes ? probably a lot quicker than writing all of 
these emails ;-)

Peter

About openEHR BMM

[Peter Gummer]

Bert Verhees wrote:

 I have a problem with both archetype-editors, I explained a few times on this 
 list why. 
 Both change archetypes while loading them, f.e. one likes to add node-id's to 
 datavalues, and the other does not like that.
 There are some more incompatibilities, between the both. I forgot the details.
 Then one is not able to create demographic archetypes, also a problem.
 -
 Both are not configurable. 
 I would like to have an archetype editor which can be feeded with some 
 RM-definition, and configured to use it, and then is being able to create 
 archetypes following that definition.
 ...
 Do you know how I create archetypes (I don't if I can someone else having to 
 do it :), but I work my way in LinkEHR or the Ocean editor, and edit them 
 manually in a text-editor, with syntax-highlighting.


Hi Bert,

Problems with the Ocean Archetype Editor should be reported to 
http://www.openehr.org/issues/issues/?jql=project%20%3D%20AEPR . The Ocean 
Archetype Editor only gets worked on when we have spare time, or if there is a 
pressing business requirement for us to fix something in it, so mentioning a 
problem on a mailing list is not likely to get it fixed.

If you have examples of archetypes generated by LinkEHR that are not handled 
properly by the Ocean Archetype Editor, please attach them to your problem 
report.

Alternatively, you could try fixing it yourself. I recall that you compiled it 
under Mono a few years ago, but you had a problem that there were dependencies 
on some DLLs that only worked under Windows. We have removed those 
dependencies, so you should be able to build it successfully under Mono these 
days.

But I understand that you're a very busy guy yourself, so submitting a problem 
report would probably be best ;-)

Peter

The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]

[Peter Gummer]

Bert Verhees wrote:

 And of course, good non-GUI-building archetype-editors which are still not 
 there, the complains I had about the both mainstream archetype-editors were 
 admitted, but the improvement did not yet come.


Hi Bert,

I remember that you described some inconsistencies on one of the mailing lists 
last year, but you need to report issues to the problem tracker if you really 
want them fixed. There's a link here for reporting problems:

http://openehr.org/downloads/archetypeeditor/home

... although the Jira problem tracker appears to be down at the moment.

Peter

The Truth About XML was: openEHR Subversion = Github move progress

[Peter Gummer]

Tim Cook wrote:

 On Thu, Apr 4, 2013 at 8:40 AM, Ian McNicoll
 Ian.McNicoll at oceaninformatics.com wrote:
 
 
 You are conflating two quite different issues.
 
 
 I don't think so.  I demonstrated what the specifications have to say
 on the matter.
 Then pointed out that an internationally respected expert on ADL and
 archetypes states that this situation is unacceptable.
 The two issues are not a conflation.  They are specifically inter-twined.


Well, Tim, I just went back and had another look at the relevant few minutes of 
the Google hangout (http://goo.gl/UP2Z1 at around 1:05) and what I see is Bert 
explaining how he works around the potential for conflicts in the ADL 1.4 
archetype IDs (which sound similar to the workarounds that Ian just mentioned), 
and Dr. Kalra replying that workarounds like that aren't going to work 
globally. None of that is controversial. The problem was acknowledged years ago.

Then on the other hand you were quoting from the ADL 1.5 specs, which introduce 
the concept of namespaces to the archetype IDs, in order to solve the problem 
that Bert was describing.

So I don't really see why you say that Dr. Kalra was responding to the ADL 1.5 
namespace specs. They aren't mentioned at all in that Google hangout video, as 
far as I can see.

Peter

ADL Workbench command line tool

[Peter Gummer]

Roger Erens wrote:

 Finally, the link to the download page of the command line compiler
 links to that of the AWB.



Hi Roger,

That's correct. The command line compiler is part of the ADL Workbench 
installation.

Peter

ADL Worbench for Linux

[Peter Gummer]

On 18/01/2013, at 20:11, Seref Arikan wrote:

 from the top of my head: reads like a path problem with the images embedded 
 into AW, due to fact that it is being developed under Windows, and you're 
 trying to run it under Linux. 


Yes, an image path problem; but no, ADL Workbench is cross-platform. It works 
under Linux just as well as Windows. Regardless of the platform, the image 
files have to be in the correct place.

Bert, did you build this yourself or did you install it from 
http://www.openehr.org/downloads/ADLworkbench/home ?

Peter

ADL Worbench for Linux

[Peter Gummer]

On 18/01/2013, at 21:55, Seref Arikan wrote:

 I know it is cross platform :) That is why I wrote, developed under 
 Windows, which implies that the developer might have used Windows style 
 relative paths for images. 


No, we don't. There is nothing Windows-specific about ADL Workbench. It really 
is cross-platform :-)

Bert's problem looks like the normal error you would get, regardless of the 
platform, if you haven't installed the files where they belong. So I'm waiting 
for him to answer my earlier question ...

Peter

Problem with specialization using the Archetype Editor

[Peter Gummer]

pablo pazos wrote:

 I'm testing archetype specialization using the AE, but I can't find a way to 
 redefine a constraint of the parent archetype inside the specialized one.
 The problem is that the AE doesn't show the nodes of the parent archetype on 
 the specialized one.


Hi Pablo,

AE is currently still stuck on ADL 1.4, so it doesn't support differential 
archetypes as defined in ADL 1.5.

Therefore, when you work on a specialised archetype in AE, you will see the 
parent's nodes only if they were copied from the parent archetype. This works 
okay (more or less) as long as the specialised archetype was created when work 
on the parent archetype had already been completed. On creating the specialised 
archetype, everything is copied from the parent. Where it fails, however, is 
that if there have been further modifications to the parent archetype, after 
the specialised archetype was created, the new changes don't magically appear 
in the specialised archetype: someone has to copy those changes manually from 
the parent.

This is a maintenance problem. Fixing this is one of the main benefits of ADL 
1.5.

By the way, Pablo, I think you mentioned recently that you were still using AE 
2.2.779. There have been a lot of improvements to how AE handles specialisation 
since then, so I recommend that you install the latest release. (Although it 
won't fix problems intrinsic to ADL 1.4, of course.)

Peter

Problem with specialization using the Archetype Editor

[Peter Gummer]

pablo pazos wrote:

 I think it would be better if the AE copies the parents nodes into the 
 specialized archetype when the AE user clicks on File  Specialize, of 
 course, only when the ADL version is 1.4.
 Manual copying is error prone. What do you think?


I'm not sure, but I think that when you upload a specialised archetype to CKM 
it validates it against the parent. You can also use ADL Workbench to validate 
it.

Nonetheless, that's a nice suggestion, Pablo. It would need to be a new menu 
item, since File | Specialise already does something (i.e., it creates a 
specialisation of the specialisation). Maybe File | Update Specialisation?

It would take a while to implement something like that, however, because we'd 
have to make sure it handled everything properly. Even then, I'm sure that 
corner cases would remain where the specialised archetypes got out of step.

ADL 1.5 is the only real solution. I'd rather put that effort into moving to 
ADL 1.5.

Peter

defaultValue/assumedValue in CPrimitive.

[Peter Gummer]

Ian McNicoll wrote:

 Assumed value: This is a statement in an archetype which asserts what should 
 happen if a value is missing. It can really only apply safely to an element 
 is Observation/State or in a Cluster archetype intended for use in state.


Ian, it's not only CLUSTER archetypes that can appear within the state of an 
OBSERVATION archetype:

* An ELEMENT archetype can similarly be slotted into the OBSERVATION.state.

* We should also allow it in EVENT.state. (That's the Person State check box 
that you see in the Archetype Editor when working on an OBSERVATION.)

* The Person State can be defined by an embedded archetype of type ITEM_SINGLE, 
ITEM_LIST, ITEM_TREE or ITEM_TABLE.


So if the idea is that assumed value should be used only to describe state, 
then I think that the complete list of places where it would be needed is in:

* OBSERVATION.state
* EVENT.state
* CLUSTER archetypes
* ELEMENT archetypes
* ITEM_SINGLE archetypes
* ITEM_LIST archetypes
* ITEM_TREE archetypes
* ITEM_TABLE archetypes

Peter

Problem specifying transition constraint on an ACTION pathway

[Peter Gummer]

pablo pazos wrote:

 It seems there's is a problem in the Archetype Editor when trying to specify 
 pathway transitions on an ACTION archetype. If I select the prescribe state 
 in the medication pathway (openEHR-EHR-ACTION-medication.v1) and check on 
 transition allowing transitions to Suspended and Abort, the ADL is 
 unchanged. 
 
 Is this a bug? I'm using Archetype Editor v2.2.779 Beta
 
 Look the screen captures here: 
 https://plus.google.com/109540968085207927247/posts/73jJSa8THSZ


Happy new year, Pablo.

Yes, it looks like a bug to me. If I save an ACTION archetype with those 
Suspended and Aborted boxes set, when I reopen the archetype they are not 
set.

The same problem also happens in the latest beta release, 2.2.876.

I tried this in some very old versions of Archetype Editor too. They have the 
same problem. So it looks like those check boxes have never worked.

Peter

Issue (probably known) with ADL Workbench

[Peter Gummer]

pablo pazos wrote:

 Hi Ian, Peter was right, the issue was because I've installed ADLWB 
 v1.4.1.595 in my notebook.
 
 I downloaded the ADLWB from here: 
 http://wiki.oceaninformatics.com/confluence/display/TTL/ADL+Workbench+Releases
 And this page lead my to the old download page: 
 http://wiki.oceaninformatics.com/confluence/display/TTL/ADL+Workbench
 
 That last link is the first result when adl workbench is searched using 
 google. Maybe that page could be updated to link the new ADLWB download page: 
 http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html


Maybe google is doing that because the proper download page (on openehr.org) 
has a heading of AWB Home and a title of ADL 1.5 Workbench. I guess google 
gets as confused by acronyms as I do ;-)

I've edited the ADL Workbench page that you found on the Ocean wiki. The 
Current Release now links to the openehr.org download page.

Thanks for pointing this out, Pablo.

Peter

Issue (probably known) with ADL Workbench

[Peter Gummer]

Ian McNicoll wrote:

 Are you using the openEHR or Ocean version of the archetype editor?


That would make no difference, Ian. The same ADL is generated by openEHR and 
Ocean Archetype Editors.

I'm sure that the problem is that Pablo must be using a very old version of ADL 
Workbench.

Peter

Possible unknown issue with Archetype Editor

[Peter Gummer]

Athanasios Anastasiou wrote:

 Is there a known problem with the following archetypes?
 openEHR-DEMOGRAPHIC-CLUSTER.individual_credentials_iso.v1
 openEHR-DEMOGRAPHIC-CLUSTER.person_additional_data_br.v1
 openEHR-DEMOGRAPHIC-CLUSTER.person_birth_data.v1
 
 If not, could there be something with the Archetype Editor? It refuses to 
 load these archetypes properly whether it's from the Open from web option 
 or by trying to open an ADL downloaded straight from the CKM.


Hi Athanasios,

Definitely a known issue ;-)

The Archetype Editor has only ever worked with the openEHR-EHR reference model. 
It was always planned to add support for openEHR-DEMOGRAPHIC, but improving the 
support for openEHR-EHR has always been a bigger priority.

You would be able to load these archetypes in the ADL Workbench, but it doesn't 
have editing capability. ADL Workbench can validate the archetypes, however, 
which is useful if you have edited the ADL in a text editor.

Peter

SMART platform and RDF

[Peter Gummer]

Seref Arikan wrote:

 If you go to RDF without XSD as the intermediate output, I'll ask: from what 
 computable form you are going to go to RDF?


I assumed it would be from OPT (operational template).

Peter

ADL Workbench - beta 7 release

[Peter Gummer]

Timothy Cook wrote:

 Do you plan to build Linux binaries?   BTW: The 32 bit (beta-5) also runs on 
 64 bit machines (Ubuntu 11.04 Intel Duo Core2)


Hi Tim,

There's a Linux build up there now, as well as a build for Mac OS X Lion.

- Peter

DV_ORDINAL C_DV_ORDINAL

[Peter Gummer]

Bert Verhees wrote:

 The OCEAN-editor creates a C_DV_ORDINAL which is empty in the definition but 
 handles the constraint in the term-defitions
 ADL-part:
 C_DV_ORDINAL 
 
 And in the term-definitions, it looks like this (it is under the NodeID from 
 the parent ELEMENT)
 [at0004] = 
description = *
a1 = een
text = New element
a2 = twee
 


Hi Bert,

This seems to be the day for Archetype Editor questions ? first Pablo, and now 
you :-)

How did you create that with the Ocean editor? Sure, you'll get this if you 
simply add an ordinal and don't constrain it:

 C_DV_ORDINAL 
 


But how did you get that other a1 and a2 stuff in the term definitions section? 
That is not what you get if you add ordinal constraints.

If you constrain the ordinal, the Ocean editor generates this:

ELEMENT[at0001] occurrences matches {0..1} matches {
-- New element
value matches {
1|[local::at0002],  -- een
2|[local::at0003]   -- twee
}
}

And in the term definitions you get:

[at0001] = 
text = New element
description = *

[at0002] = 
text = een
description = *

[at0003] = 
text = twee
description = *


Which is how ordinal constraints have always been expressed in archetypes, as 
far as I'm aware.

Peter

Archetype Editor bug on save after translation

[Peter Gummer]

Ian McNicoll wrote:

 I did have a go at fixing this but it turns out to be a nontrivial problem.


Actually you did fix a very similar problem, Ian, in July last year. But it 
only fixed the primary language. The problem is still happening in different 
languages, such as Pablo's example.

Pablo, I've created a problem report for Archetype Editor with the steps that 
you provided. I may get a chance to look at it in a week or two ? unless Ian 
beats me to it ;-)

Peter

Improvement proposals to the Archetype Editor

[Peter Gummer]

pablo pazos wrote:

 I have some proposals that might improve some aspects of the AE:
 ...
 - the translation is very poor, how can I translate the GUI terms?

That would be great, Pablo.

Under the directory where Archetype Editor is installed, there's a directory 
called Terminology. You can edit the terminology.xml that you find there. 
It's pretty straightforward to edit the XML directly, but there's a program 
called openEHR_Translation.exe in the same directory which you'll probably find 
makes it easier.

If you send me your improved copy of terminology.xml, I'll commit your changes 
to the Archetype Editor Subversion repository.


 - is there some way to do a search on the AE GUI that consumes a search 
 service on the CKM to find, download and edit/specialize archetypes from the 
 CKM directly from the AE?

In the Tools | Options dialog, select the File Locations tab. Turn on the 
Enable Internet Search check box. (The URL should be 
http://openehr.org/knowledge/services/ArchetypeFinderBean?wsdl)

Then, under the File menu, you'll see an option to Open from Web? This allows 
you to get archetypes directly from CKM.

Peter

Archetype Editor bug on save after translation

[Peter Gummer]

pablo pazos wrote:

 Several students have experienced problems using the Archetype Editor. When 
 they add a new language to translate an archetype, then save the changes, the 
 changes are not saved.
 
 Anyone else is experiencing this problem?


Which version of Archetype Editor are they using Pablo?

There's a known problem that was introduced in the version 2.2.601 beta 
release. The problem still exists in the latest 2.2.779 beta release. Editing 
the comments field could cause an InvalidCastException if the user answered yes 
to the question whether to replace translations. The problem has been fixed, so 
if this is the problem that you're running into we could do another beta 
release with the fix.

Are you seeing this, or a different problem?

Peter

How about creating an openEHR test base?

[Peter Gummer]

Hi Pablo,

It makes more sense to me to add all of that to the existing repository rather 
than fragmenting the effort.

- Peter


On 06/05/2012, at 22:28, pablo pazos wrote:

 Hi Peter, thanks for the pointer.
 
 I think this is only ADL related and only 1.5. My idea is to include ADL1.4 
 and RM instances in XML and JSON, RM  AOM XSD, also term sets.
 Maybe we can took some samples from there, but I believe this new repo has a 
 wider scope. What do you think?
 
 -- 
 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
 
  Subject: Re: How about creating an openEHR test base?
  From: peter.gummer at oceaninformatics.com
  Date: Sun, 6 May 2012 21:39:25 +1000
  To: openehr-technical at lists.openehr.org
  
  pablo pazos wrote:
  
   I have proposed here *** that we can start attaching files to the wiki 
   and linking them under our names, each one of us can describe each 
   artifact, what issues it has, what tweaks and fixes have made over those 
   artifacts, etc.
  
  Hi Pablo,
  
  I get the impression that you aren't aware that this test repository 
  already exists:
  
  http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test
  
  Have you considered building on this, rather than starting a whole new 
  repository?
  
  - Peter

How about creating an openEHR test base?

[Peter Gummer]

Diego Bosc? wrote:

 I would say the scope of that repository is different, as that is part
 of the test for current evolving 1.5 syntax and does not include
 'real' archetypes

My understanding was that Pablo was not proposing real archetypes either. In 
his original post, Pablo proposed a test base with sample artifacts.

How would this be different from the purpose of the existing 
http://www.openehr.org/svn/knowledge2 repository? The only difference that I 
can see is that Pablo has proposed adding a greater variety of artefacts (OPTs, 
etc.), so it seems natural to add them to the existing repository.

- Peter

How about creating an openEHR test base?

[Peter Gummer]

pablo pazos wrote:

 I have proposed here *** that we can start attaching files to the wiki and 
 linking them under our names, each one of us can describe each artifact, what 
 issues it has, what tweaks and fixes have made over those artifacts, etc.

Hi Pablo,

I get the impression that you aren't aware that this test repository already 
exists:

http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test

Have you considered building on this, rather than starting a whole new 
repository?

- Peter

13606 revisited - list proposal

[Peter Gummer]

Thomas Beale wrote:

 pablo pazos wrote:
 
 Consider this ER scenario: a BP value could be recorded each 30 or so, and 
 the system could be used 1. for many patients, 2. by many users, 3. on the 
 same machine.
 
 this is most likely a 1-event-per-Observation scenario. I realise it is not 
 always obvious when to use which recording approach! But the other design 
 aspect of a COMPOSITION is that it is a 'single health system event for the 
 patient'. Here it sounds like 1 nursing observation every 30 mins. Therefore 
 we would expect 1 COMPOSITION for each one, each containing one OBSERVATION, 
 containing one EVENT.

An important consideration here is the composer of the composition. Different 
nurses will be recording the readings during the course of the day (or days, or 
weeks ...), but each composition can have only one composer. (You could get 
around that by adding an updated version of the composition with each reading, 
so the latest version would contain all of the data, but that would be a truly 
baroque approach! It would make it difficult to figure out which nurse had 
recorded which reading.)

Another consideration is that the nurse is likely to be recording other 
observations at the same time as the BP. It seems logical to me that all of 
these observations should go into the same composition, because they were all 
done at the same time, by the same committer, for the same subject of care.

On the other hand, if the BP readings are coming from a patient monitor, say, 
every 30 seconds, then it would make sense to store all of these BP readings in 
one composition. When would you decide, okay, that's enough, let's start 
another composition? Maybe every hour? Each day? Or maybe at the point in time 
when a clinician reviews them and says, Yep, I've reviewed those BPs, commit 
'em?

Peter

13606 revisited - list proposal

[Peter Gummer]

Grahame Grieve wrote:

 well it is the case for the History/Event structure - by definition. If you
 have a situation where it is not the case - there are many! - then this is
 not the data structure to use; just use separate Observations (possibly with
 LINKs between them).
 
 well, currently, that means that we have to break up what is a simple single
 archetype otherwise into a set of archetypes, and we have poor binding between
 them.

I don't think Thomas was suggesting multiple archetypes. I think he was saying 
that you would have multiple data instances of the one OBSERVATION archetype.

Peter

Suggestion to replace use of generics with inheritence in future RM versions

[Peter Gummer]

David Moner wrote:

 I was exaclty thinking about this while seeing this proposal for the 
 ITEM_STRUCTURE change to a VALUE_CLUSTER:
 
 http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.1AddVALUECLUSTER%2CRemoveITEMSTRUCTUREtypes
  
 
 It is an example of multiple inheritance not supported by Java and some other 
 languages.


Multiple inheritance is easily implemented in Java and C# ... via interfaces.

The problem is that you often need to duplicate code. For example, in that 
diagram, VALUE_CLUSTER inherits from both ELEMENT and CLUSTER. In C# you can't 
do that, so you would probably declare ValueCluster as implementing two 
interfaces, IElement and ICluster; then you would copy the implementations of 
Element and Cluster into ValueCluster. Java would do something similar, 
although the naming convention of the interfaces might be different. (In C#, 
you might even decide to avoid some of the code duplication by using extension 
methods. Or maybe not ... it might cause more trouble than it solves.)

Peter

Suggestion to replace use of generics with inheritence in future RM versions

[Peter Gummer]

Shinji KOBAYASHI wrote:

 Ruby implementation might be one of the proof for replace of generics.
 I had much struggled to implement generics and got the conclusion
 that we do not need it.

Ruby doesn't have generics at all, right, Shinji?

There's a comparison of generics and inheritance in an appendix of Bertrand 
Meyer's Object Oriented Software Construction, 2nd edition. 
(http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the original 
paper that the appendix is based upon.)

Generics can be simulated in a language with inheritance, but there is a cost:
* Duplication of code.
* Extra verbosity.

I don't want to have either forced upon me. If I'm unfortunately forced to use 
a language that doesn't support generics, then I can always simulate it the 
generics with inheritance. But I certainly wouldn't want the specs to be 
obfuscated by hacks like that, thanks very much ;-)

Peter

Suggestion to replace use of generics with inheritence in future RM versions

[Peter Gummer]

Shinji KOBAYASHI wrote:

 IteratorDvText it = someRmArrayInstance.iterator()
 
 But I found it must be cut off by 'Occam's razor' in Ruby.
 
 it = some_rm_array.iterator
 
 This code looks curious for Java/Eiffel/C# user who are similar to generics,
 but it is enough for encapsulated object instance.

Ruby is a dynamic language, so I guess it would have no need for generics. If 
you provide a wrongly typed object to a collection in Ruby, I imagine (never 
having programmed in Ruby myself) that you would find out about the error when 
you run the program.

Eiffel, C# and Java try to catch errors like that during compilation. Generics 
is useful for those languages: it tries to keep the extra safety of 
compile-type checking, while providing some of the flexibility that you get in 
dynamic languages like Ruby.

In the case of Java, generics don't work very well, as Seref pointed out. The 
JVM forced the Java designers to adopt a policy of type erasure. And so, on 
the one hand, the compiler is less flexible than Eiffel and C#, rejecting a lot 
of uses of generics that would be permitted in those other languages; and on 
the other hand, the Java byte code that you finish up running in the JVM 
contains no info about the generic parameter type.

I'm not clear why the existence of generics in the spec would be a problem for 
a dynamic language like Ruby.

Peter

openEHR-technical Digest, Vol 67, Issue 34

[Peter Gummer]

Hi William,

I think you may have misread who wrote what. The assertion that HL7 is 
proprietary was made by Fred Trotter, not by Heath.

Peter


fred trotter wrote:
 ...
 Having said that, HL7 RIM is a proprietary ontology/model and OpenEHR, is
 not.

William Goossen wrote:

 Ar this stage membership is open to anyone for both HL7 and OpenEHR. Hence 
 they are both open. Difference is that HL7 is an SDO and OpenEHR a community. 
 But yes both have their copyright approaches. I have not gone through each of 
 them in detail. But as a user of both platforms it does not make a 
 difference, in contrast to what Heath said.

Constraints on class methods

[Peter Gummer]

Heath Frankel wrote:

 I believe this unique name rule should be reviewed and revoked. It is not 
 formally defined, as indicated in [ 
 http://www.openehr.org/issues/browse/SPECPR-54 ] its only stated in the 
 architecture overview in the context of paths which assumes name is the 
 unique within a container. I have other examples where it is desirable to get 
 multiple items with the same node-id but not the entire set and name is the 
 obvious collector. It also causes issues in renamed templated items which you 
 still want to allow more than one occurrence of that item.

I certainly agree with all of that Heath, having been frequently frustrated 
myself by this unique name rule.

I thought that ADL 1.5 had resolved this issue a couple of years ago, hadn't 
it? We're still using ADL 1.4, though, so we are still stuck with the old rule, 
and I can't remember what the resolution was.

If ADL 1.5 does revoke the unique name rule, then PARTY_RELATIONSHIP's type = 
name constraint could stay, in some form, depending on the outcome of this 
discussion about constraints on functions.

- Peter

Constraints on class methods

[Peter Gummer]

Sebastian Garde wrote:

 A few other functional properties come to mind such as type in 
 PARTY_RELATIONSHIP ...
 Re type: This is the same as the property name (because of the 
 type_validity invariant)

Yes, funny you should mention that, Sebastian, because I discovered yesterday 
that this is a bug in the spec. As is well known, the name must be unique 
among siblings within a container. This uniqueness is incompatible with the 
PARTY_RELATIONSHIP type, because it would be common for a party to have 
multiple relationships of the same type.

http://www.openehr.org/issues/browse/SPECPR-54 discusses this. I had to find a 
work around for it in my software. I chose to violate the type_validity 
invariant: when setting the type, I append a sequential number to it to set the 
name; and I compute the type by stripping the sequential number off the name. 
This ensures that the name is unique, while permitting multiple siblings of the 
same type.

- Peter

Carriage returns in DV_TEXT not allowed

[Peter Gummer]

Thomas Beale wrote:

 This does not actually solve properly the problem of how CR/LFs are added. If 
 we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing) then a report 
 needs to consist of multiple DV_PARAGRAPHs, and we don't currently have a 
 data type for that. To fix the current model we could add a new type 
 DV_DOCUMENT,   which contains multiple DV_PARAGRAPHs.

You could model multiple paragraphs as a LIST of DV_PARAGRAPH.

I think the DV_DOCUMENT idea would be unnecessary, unless you wanted to specify 
additional information such as sections or chapters within the document.

- Peter

Carriage returns in DV_TEXT not allowed

[Peter Gummer]

Thomas Beale wrote:

 You could model multiple paragraphs as a LIST of DV_PARAGRAPH.
 
 but there is no 'LIST' data type to contain the DV_PARAGRAPHs.

Sorry, not a LIST, I meant a multiple-occurrence element like this:

ELEMENT[at0009] occurrences matches {0..*} matches {-- My document
value matches {
DV_PARAGRAPH matches {*}
}
}

In data this would become a sequences of paragraphs.

By the way, I wanted to generate the above ADL in Archetype Editor, but I 
discovered that DV_PARAGRAPH hasn't been implemented there yet! There's never 
even been a feature request for DV_PARAGRAPH in Archetype Editor. To write the 
above example, I had to generate another data type in AE and then edit the data 
type by hand. I guess it would be safe to assume, then, that almost no one 
would be using DV_PARAGRAPH.

- Peter

Carriage returns in DV_TEXT not allowed

[Peter Gummer]

Colin Sutton wrote:

 Couldn?t the text stored in the eHR include HTML paragraph separators, 
 replacing Windows or Unix specific line separators?
 And HTML escape sequences?.
  
 DV_HTMLTEXT?

That's what DV_PARSABLE is for, as Thomas mentioned ;-)

- Peter

termbinding constraints in the archetype editor

[Peter Gummer]

Jostein Ven wrote:

 I am trying to bind an attribute in an archetype to a value set from a 
 terminology server. The data in the termserver is availiable through web 
 services. In practice, it should thus be possible to specify a URI in an 
 archetype constraint for the elementattribute. Can't figure out how this is 
 meant to be done in AE. Anyone with experience of how to do this in practice? 

Hi Jostein,

This depends whether you got AE from the openEHR web site or from Ocean 
Informatics.
* The openEHR build lacks a way of of connecting to a terminology server.
* The Ocean informatics build, on the other hand, uses a proprietary component 
to connect to the Ocean Terminology Server (OTS).

Why have two builds? Because AE is open source, and the inclusion of a 
proprietary component would prevent people from being able to build AE 
themselves. But people want this functionality, so the only solution was to do 
a separate Ocean build of AE, with the appropriate hooks to connect to OTS. In 
theory, any one who has the time and expertise could use those same hooks to 
connect to some other terminology service.

So, once you've installed the Ocean build of AE, here's how to do it. First you 
have to configure AE to point to the web service that you want to use:

1. Under the Tools menu, select Options.

2. In the Options dialog, select the File Locations tab.

3. Tick Enable Terminology Lookup. (This is not available in the openEHR 
build.)

4. Enter the web service URL into the URL for Terminology Service box. (This 
isn't in the openEHR build either.)

5. Click OK.

Then you can set term bindings and constraint bindings. This can be done on the 
Definition tab.

To set a term binding, select the element that you want to bind to a term. 
Then, over on the right, select the little Details tab. Towards the bottom is a 
box, Node meaning in terminologies, containing an empty grid. Click the 
button in the top row of the grid. This will show a dialog where you can select 
your binding.

To set a constraint binding on a DV_CODED_TEXT, select the text element that 
you want to bind. Over on the right, select the Terminology radio button. 
This will display an empty grid down below. Click the [+] button. This will 
show a dialog where you can add your binding.


 Does anyone know what the AE does when you enter the interface screen. Is the 
 constraint executed, if not, when is the constraint executed (or is it 
 executed at all?).

Term binding constraints aren't executed on the Interface tab. The Interface 
tab doesn't do anything really. Its only purpose is to give you a bit of an 
idea of how a hypothetical form based this archetype might look. I never use it 
myself, but I've noticed that it seems to help some people visualise their 
archetypes.


 References to AE user manual is also welcome. Can't find this.

Under the Help menu, select Help Topics. This opens up 
http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html
 and from there you can follow a link to more detailed help.

AE's online help hasn't been revised for more than five years, however. It's 
out of date in places. For example, it doesn't describe what I've written 
above, because it was only implemented a year or two ago, but it does describe 
an alternative way using the Terminology tab.

- Peter

13606 revisited - list proposal

[Peter Gummer]

Erik Sundvall wrote:

 [ABSTRACT_CARE_ENTRY]^[CARE_ENTRY|data: ITEM]
 [CARE_ENTRY]-[note:CARE_ENTRY Replaces both ADMIN_ENTRY and EVALUATION.]
 [ABSTRACT_CARE_ENTRY]^[OBSERVATION|data: EVENTS;0..1 state: EVENTS]
 [ABSTRACT_CARE_ENTRY]^[INSTRUCTION]
 [ABSTRACT_CARE_ENTRY]^[ACTION]

Hi Erik,

So the basic distinction between ADMIN_ENTRY and the clinical entry types would 
be lost. This feels strange to me, to be using the same CARE_ENTRY class for 
clinical and non-clinical entries.

I'm particularly nervous that EVALUATION, the product of an important step in 
patient care, would disappear into the same class as administrative entries. 
Apart from not feeling nice when I look at a class diagram, mightn't this have 
the practical consequence of making it difficult to write AQL queries to search 
for clinical evaluations? Maybe not ... in AQL, you normally select from some 
archetype by its id, which includes the concept as well as the class ... so it 
would be select from openEHR-EHR-CARE_ENTRY.risk.v1, instead of select from 
openEHR-EHR-EVALUATION.risk.v1. I'm not sure whether it's even possible to 
select from all evaluations without mentioning their concepts.

- Peter

13606 revisited - list proposal

[Peter Gummer]

On 17/12/2011, at 8:43, Diego Bosc? wrote:

 I am reading 1.0.2 IM and it says CARE_ENTRY, not GENERIC_ENTRY. which
 one is the good one?

GENERIC_ENTRY is described in the integration_im.pdf. It's a sibling of ENTRY 
in the inheritance hierarchy.

- Peter

openEHR Transition: Web-based tools?

[Peter Gummer]

Erik Sundvall wrote:

 I agree with Seref. ...

 If effort is put into new tools it might be good idea to do at least
 the GUI in HTML5 etc.

That rules out all of those corporate users that Seref and Ian  
mentioned who are stuck on IE6, doesn't it?

- Peter

openEHR Transition: Web-based tools?

[Peter Gummer]

Pablo Pazos wrote:

 Web developers can easily tackle those problems ...

I'm afraid the word easily is wrong, Pablo. I've been doing mostly  
web development for the last few years. I specifically mentioned those  
things because they are _hard_ to do in in web development, whereas in  
desktop applications they are extremely easy to do or, in the case of  
session time-outs, the problem doesn't exist at all.

 Just use HTML: http://en.wikipedia.org/wiki/Access_key

This doesn't address keyboard shortcuts. Access keys are not keyboard  
shortcuts. I'm sure there must be some way to do keyboard shortcuts in  
a web application, because googling for cloud9 keyboard shortcuts  
comes up with some relevant-looking results, but I really have no idea  
how to achieve it.

It also doesn't address at all my question about setting focus to the  
appropriate control automatically. When I open a page, I want keyboard  
focus set to a sensible place, probably the top-left entry control. If  
I select an item from a drop-down list, I probably want focus to  
remain on that drop-down list. If there's an OK or Save button on the  
page, then I should be able to click it without being forced to reach  
for the mouse. Simple usability stuff that is programmed routinely  
with almost no effort into a desktop app, and that is essential for me  
personally, if I am to spend hours on end, day after day, using that  
application. My experience of trying to get basic stuff like this  
working properly in a web app is that it's doable, but with a huge  
amount of effort.


 One way to maintain a session open is to send heartbeats using  
 AJAX ...

That's interesting. When I have a whole day free to investigate, I  
might work out a way to implement this for my current project.  
Hopefully that day won't turn into a week, as such things have a  
tendency of doing :-(

Anyway, this pretty well proves my point. The problem simply doesn't  
exist in desktop apps, but in developing a web app you have to devote  
significant time to this problem instead of working on real  
functionality. These are just a few examples of the many things that I  
take for granted when programming desktop apps that suddenly become  
very difficult for web apps ...

- Peter

openEHR Transition: Web-based tools?

[Peter Gummer]

Seref Arikan wrote:

 ...  Unfortunately, most modern
 software development technologies arrive with their own runtimes,
 (.net framework, jre etc) and it quickly becomes a nightmare to deploy
 and update software.

I'm not aware of any such deployment problems with .NET. I'm sure  
there must be some, somewhere, but they must be edge cases. In ten  
years of .NET development I haven't bumped into them. Different  
versions of .NET sit side-by-side on the same machine just fine; ditto  
for DLLs targeted towards different .NET versions. My daily work  
involves a .NET 4.0 application that has dependencies on a lot of .NET  
2.0 DLLs; it just works seamlessly.

- Peter

openEHR Transition: Web-based tools?

[Peter Gummer]

Seref Arikan wrote:

 90% of the time problem is about the IT policies of the institutions.
 If you develop with .NET 4.0, which would require a .net framework 4.0
 runtime, you assume that the people using the software would be able
 to install the runtime, and install the software.

Yes, that's a problem I have run into once or twice. It's the perfect  
argument for developing Eiffel native executables. The problem then,  
of course, is that support may be less than perfect for the system  
that you want to run the application on. Getting behind the effort to  
get Eiffel running better on those platforms would be the quickest and  
most effective way to go, in my opinion.

 ... web based apps a much better option when it comes to this
 particular aspect of software life cycle.

But web based apps bring their own set of problems that desktop apps  
don't have. Ian has been talking about poor usability.

* How do you do keyboard shortcuts in a web application? How do you  
set keyboard focus to the appropriate widget to maximise ease of use?  
Both of those can be achieved in a web app, but it's extremely  
difficult.

* How do you recover gracefully when the user's session times out?  
Imagine you're in the middle of working on an archetype, you spend 20  
minutes talking to a colleague or answering emails, and your web  
session times out. All of your work is gone. There are ways to handle  
this gracefully, but they are are horribly difficult to program. This  
problem simply doesn't exist with desktop apps.

* How do you design your application so that it performs well without  
putting half of your business logic into Javascript that is riddled  
with hacks for handling old browsers?

- Peter

Which code in code_string symbol for DV_ORDINAL?

[Peter Gummer]

Leonardo Moretti wrote:

 I have clear how to use terminology_id and code for DV_CODED_TEXT,  
 but here
 I'm wondering if I can use the ordinal (integer) value as coded  
 value in a
 DV_ORDINAL, like in this example (note: code_string5/code_string):
 ...
  terminology_id
valuelocal/value
  /terminology_id
  code_string5/code_string

No, Leonardo, you can't do that. The ordinal's value and the code  
string are different things. The code string must be a member of the  
terminology. In your example, the terminology is local, which means  
that it's an at-code.

Imagine that the coded text used a different terminology. Imagine that  
this terminology had codes like 1, 2, 3, 4, 5, etc. If this  
was your terminology, then of course your code string could be 5.

- Peter

C_DATE_TIME and RM instances

[Peter Gummer]

Leonardo Moretti wrote:

 ELEMENT[at0061] occurrences matches {0..1} matches { -- Date/Time  
 element
 value matches {
 DV_DATE_TIME matches {*}
 }
 }
 ...
 Or for the latter we need to use DV_DATE and DV_TIME rescpectively  
 (remember we have defined a C_DATE_TIME constraint in archetype)?

That would not be possible, Leonardo, because DV_DATE and DV_TIME do  
not inherit from DV_DATE_TIME.

- Peter

null value of Element

[Peter Gummer]

Bert Verhees wrote:

 ELEMENT[at0033] occurrences matches {0..1} matches {-- Condition  
 Status
value matches {
   DV_TEXT matches {*}
}
 }
 ...

 Is it so that in an archetype-snippet like this, value is a required
 attribute?

According to the openEHR data structures specification, ELEMENT.value  
is 0..1. It's optional, as long as a null flavour is supplied.

Invariants:
Is_null_valid: is_null = (value = Void)
Null_flavour_indicated: is_null xor null_flavour = Void

In other words, (value = Void) = not (null_flavour = Void). The  
ELEMENT must have either a value, or a null flavour, but not both.

- Peter Gummer

constraint binding error

[Peter Gummer]

Diego Bosc? wrote:

 I know it is on ADL specs, but why limit it to an URI? Second approach
 could also be used to identify a subset

The URI approach is able to specify subsets, Diego. Here is an  
example, generated by the current Archetype Editor beta release  
(available from 
http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html)
 
:

constraint_bindings = 
[Snomed] = 
items = 
[ac0001] = 
terminology:Snomed/2002?subset=DrugForm




- Peter

constraint binding error

[Peter Gummer]

Diego Bosc? wrote:

 And again not that difficult to support both kind of bindings. In my
 opinion, ORGANIZATIONX::DrugFormSubset is way more human
 readable and needs the same degree of 'computer interpretation' than
 the URI terminology:...

I would agree that the TERMINOLOGY::subset form may be more legible  
to humans.

For computer interpretation, however, it would be a big problem. How  
would an ADL parser know whether the value of the constraint binding  
was a URI or not?

The ADL ontology section is a serialisation of the ontology AOM. Page  
78 of 
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf
 
  specifies that the ARCHETYPE_ONTOLOGY class's constraint_bindings  
attribute contains DV_URI objects. This proposed TERMINOLOGY::subset  
form is not a serialisation of a DV_URI, so the specification would  
have to be changed somehow or other. I doubt that the resulting  
serialisation would be the just a matter of putting a  
TERMINOLOGY::subset where currently we have a URI. There would have  
to be some way of identifying whether it's a DV_URI or not. This would  
complicate the ADL, probably not making it so nice for humans to read  
after all.

But supposing that this did get done, and the ADL parsers were able to  
differentiate whether it's a DV_URI or not. We still wouldn't have  
solved all of the problems for computer interpretation, because all  
tools which currently know how to deal with DV_URIs in the constraint  
bindings would now have to cope with the possibility of some other  
class of object. Not only would software that is currently working  
have to be upgraded, the resulting software would be somewhat more  
complicated than it is today.

- Peter

constraint binding error

[Peter Gummer]

Diego Bosc? wrote:

 and we have also to deal with spaces!
 terminology:Snomed?v=2002?s=Antiallergenic drugs (product)

Spaces are illegal in URIs. The correct form for the subset would be:

subset=Antiallergenic%20drugs%20(product)

- Peter

constraint binding error

[Peter Gummer]

Thomas Beale wrote:

 What probably does make sense anyway is to relax the spec in ADL 1.5  
 to allow both forms (and one day, probably we get rid of the URI  
 form). Does that seem reasonable?

This would mean, then, a revision to section 8.3.1 of the AOM 1.5  
spec. Currently it says that ARCHETYPE_ONTOLOGY.constraint_bindings  
contains DV_URI objects.

- Peter

constraint binding error

[Peter Gummer]

Cati Mart?nez wrote:

 [ac0001] = [CONSULTA::1]

 The ADL parser throws an error with this last one. is it right?

Hi Cati,

That last one is not a valid constraint binding. It has to be a valid  
URI.

- Peter

Why the type function of the PARTY_RELATIONSHIP retrun an instance of DV_TEXT

[Peter Gummer]

Mahdi Asgari wrote:

 Dear all,
 PARTY_RELATIONSHIP has a function named type, If type is the meaning  
 of the relationships such as employment, authority, health  
 provision, why type return DV_TEXT instead of DV_CODED_TEXT?
 By this type (DV_TEXT) we cannot use terminology coding system?

DV_CODED_TEXT is a subclass of DV_TEXT.

As a general rule, you can use DV_CODED_TEXT for any feature of type  
DV_TEXT.

- Peter

openEHR template and oet template

[Peter Gummer]

Cristian Armentano wrote:

 Is oet template a different concept with respect to openEHR  
 template described in AOM 1.5?


Yes, they are different. The oet templates are the first generation of  
templates in openEHR. They proved that the idea of aggregating  
archetypes works in reality. The 1.5 specification builds upon this  
experience.

- Peter

Use of Identifiers in archetypes

[Peter Gummer]

Grahame Grieve wrote:

 Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go
 and review it, but how does it manifest in the archetype editor?

FEEDER_AUDIT isn't shown in the Archetype Editor at all. It's one of  
many parts of the reference model invisible within the tools, and so  
easily overlooked by modellers. As Ian said, there's growing  
recognition that future tools need to rectify this.

- Peter

Use of Identifiers in archetypes

[Peter Gummer]

Grahame Grieve wrote:

 The first is that in the archetype design we came up with (still be  
 posed
 on CKM yet), there's a lot of identifiers present. These identifiers  
 are
 required to deal with the interoperability aspects of the imaging exam
 report (i.e. PACS reigsters images with RIS, RIS provides report to
 EHR, EHR tracks identifiers so it can provide links to RIS/PACS
 resources as required). In particular, in several places there's slots
 for various DICOM UIDs. To me, these are IT issues, not clinical
 issues, so they shouldn't be part of the archetype design (on the  
 basis
 that archetypes are *clinica* knowledge)- but I do know that we
 absolutely need these identifiers. Is there a policy about this?
 Note that I ask this question with wider issues about whether IT and
 interoperability concerns should be explicitly represented in  
 archetypes.



Hi Grahame,

I believe what you're saying is right. This sounds exactly like what  
the FEEDER_AUDIT class was designed for. See the the Common IM spec.

Each LOCATABLE has an attribute called 'feeder_audit', of type  
FEEDER_AUDIT. Within the FEEDER_AUDIT class, there are lists of  
DV_IDENTIFIER where systems can store ids generated by the originating  
system and other systems. The FEEDER_AUDIT also has an attribute  
called 'original_content', where an image or a reference to the image  
would be stored.

Because COMPOSITION inherits from LOCATABLE, an obvious place to set  
the 'feeder_audit' attribute might be on the composition. You could of  
course prefer to set it on, say, the imaging exam OBSERVATION.

This is an excellent example of something that is already catered for  
in the reference model, and so it probably shouldn't be modelled in  
archetypes. Unfortunately, current tools don't make the feeder_audit  
attribute visible visible to modellers, so they are likely to  
reinvent the wheel, unaware that it's already available. (They're  
designing wheels for the car, but the car already has wheels.)  
This is a problem to modellers: an important part of the model that  
they are designing is to all intents and purposes invisible to them in  
the archetype.

- Peter

More on ISO 21090 complexity

[Peter Gummer]

On 24/11/2010, at 17:42, Grahame Grieve wrote:

 hi Tom

 I can only presume this email actually predated our other discussion

I'd say so, Grahame, because the date on Thomas's email was 18th  
November, and I recall reading its content already, many days ago.

- Peter

openEHR-RM-LINK discussion - now also on mailing list :-)

[Peter Gummer]

Erik Sundvall wrote:

 openEHR-EHR-EVALUATION.problem.v1.adls
   openEHR-EHR-EVALUATION.diagnosis.v1.adls
  openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls
 openEHR-EHR-LINK.indication.v1.adls

 Should not the identifiers instead be:

 openEHR-EHR-EVALUATION.problem.v1.adls
   openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls
  openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls
 openEHR-EHR-LINK.indication.v1.adls

 Or have the identifier syntax and semantics requirements changed in
 ADL/AOM 1.5?

This has changed in ADL 1.5. The hyphen is no longer used.

I'm sure I remember Thomas starting a discussion about this on the  
mailing list about a year ago.

- Peter Gummer

What does Add reference in Archetype Editor means

[Peter Gummer]

Koray Atalag wrote:

 Hope this helps?You can look into the archetype: openEHR-EHR- 
 OBSERVATION.MST_colon.v1
 Which used to come bundled with the AE installation.

Hi Koray,

The MST_colon archetype can still be downloaded from the old, obsolete  
Subversion repository:

http://www.openehr.org/svn/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.mst_colon.v1.adl

That archetype isn't installed by Archetype Editor any more. These  
days, Archetype Editor installs a few dozen simple, representative  
sample archetypes, to help new users familiarise themselves with  
archetypes. They are clearly marked as samples to avoid mistaking them  
for real (i.e. CKM) archetypes.

openEHR-EHR-ADMIN_ENTRY.sample_admission.v1.adl contains some internal  
references.

- Peter Gummer

proposed ADL 1.5 simplification

[Peter Gummer]

Sebastian Garde wrote:

 Not sure if this change would has an impact on the canonical MD5  
 hash generated by the Archetype Editor - ideally it would be the  
 same for an archetype with or without the concept clause?


I doubt it, Sebastian. Any small changes made to an archetype today  
will cause the MD5 hash to change.

For example, open an existing archetype in a text editor and replace  
its first line:
archetype (adl_version=1.4)
With this:
archetype (adl_version=1.5)

Then open the edited archetype in Archetype Editor 2.1, select the  
Display tab and click on the ADL button to see what gets generated.  
The MD5 hash will be completely different.

A future Archetype Editor would always replace the adl_version with  
1.5 when you save an archetype, I expect, similarly to what was done  
manually with a text editor in this little experiment. This would be  
the minimal change to any archetype when migrating to 1.5.

So what I am saying is that, no matter whether anything else has  
changed in the archetype, when migrating to 1.5, it would appear that  
the MD5 hash is going to be different anyway.

- Peter Gummer

What does Add reference in Archetype Editor means

[Peter Gummer]

? ??? wrote:

 When right-clicking on any element in Archetype Editor there is link  
 Add reference which adds a readonly element to definition.

 So, what does it mean?

Hi Igor,

It's an internal reference. See the ADL 1.4 specification, section  
5.3.7.

- Peter Gummer

Should ATTESTATION.reason datatype really be DV_TEXT or rather DV_CODED_TEXT (or perhaps CODE_PHRASE)?

[Peter Gummer]

Thomas Beale wrote:
 Are end users really supposed to see the DV_TEXT.value
 of those? ...
 ... we historically decided that it was always better
 to have the original text of any coded element, in the original
 language.
 When you say in the original language, do you mean the original
 language of the archetype, or do you mean the original language that
 the user saw on the screen when the data was committed?

 it is the latter - the archetype's original language is irrelevant -  
 we are only interested in the locale language of the committing  
 user, which could easily be different.


That makes sense.

On committing the contribution, is there validation of the  
DV_CODED_TEXT.value to ensure that it is the same text as the value  
defined for the committing user's language, for that code in that  
terminology?

- Peter Gummer

Should ATTESTATION.reason datatype really be DV_TEXT or rather DV_CODED_TEXT (or perhaps CODE_PHRASE)?

[Peter Gummer]

Thomas Beale wrote:

 Are end users really supposed to see the DV_TEXT.value
 of those? I guess aplication logic and GUIs are better off trying to
 use the embedded CODE_PHRASE than relying on the possibly language
 dependent DV_TEXT.value for those fields/methods.

 a base assumption in openEHR historically is that the data might  
 arrive in some application space that doesn't have access to the  
 terminology. This can easily happen for many reasons. We don't want  
 the application to be useless (i.e. can't put stuff on the screen)  
 just because it can't see the terminology. Now, in these structural  
 attributes, you could expect that the openEHR terminology would be  
 available somewhere in the application space. However, for both  
 these situations, we historically decided that it was always better  
 to have the original text of any coded element, in the original  
 language.


When you say in the original language, do you mean the original  
language of the archetype, or do you mean the original language that  
the user saw on the screen when the data was committed?

For example, if an archetype's original language is English, but a  
user is viewing the text in Swedish, then which of the two languages  
would the DV_CODED_TEXT.value be committed in?

- Peter Gummer

distributed development, governance and artefact identification for openEHR

[Peter Gummer]

Sam Heard wrote:
 1. Primacy of openEHR: I would propose that we need a hierarchy of
 authority. Although openEHR artefacts are presently managed within the
 Foundation it is possible that the governance will move to a more
 authoritative organisation in the near future. That said, I believe that
 archetypes released by the openEHR Foundation should not be identified
 specially (i.e. no name space). This means that openEHR becomes the default
 namespace for archetypes and begins to provide a hierarchy of authority that
 I think is so important in this space. One might argue that anyone can
 produce archetypes with no namespace - but really anyone can produce
 anything with any namespace so that is not sufficient.
   

Hi Sam,

The primacy of openEHR sounds good, but wouldn't it be better to stamp 
the archetypes with the openEHR seal of approval? Your proposal above 
means that all of the home-grown local archetypes sitting on people's 
own computers at the moment are indistinguishable from the authoritative 
openEHR archetypes.

I don't buy the argument that producing an archetype with no namespace 
is equivalent to producing an archetype with any namespace:

* Archetypes with no namespace can (and will!) be produced
  frequently, innocently and by accident.
* Producing an archetype with the openehr namespace would be a
  deliberate act, a conscious choice.


- Peter

Archetyping links

[Peter Gummer]

Rong Chen wrote:
 I would say our use case for the link is also between compositions.
 For the reasons you mentioned, it would be nice to just use the
 archetypeId in the constraint for the value (URI) of the link. Then it
 starts to look like a mini query.
   

It starts looking like a kind of slot too, but whereas a slot has 
aggregation semantics (i.e. the data in the slot is owned by the 
containing archetype), a link is just an association. So maybe links 
could use the same regular expression patterns that slots use.

- Peter

Item_Tree

[Peter Gummer]

Ian McNicoll wrote:
 We are finding that it is much more common to want to reuse only 
 *parts* of an archetype and I think you might be better to think of 
 using CLUSTER archetypes.

That's true, Ian, but it doesn't really explain why you're not allowed 
to embed an Item_tree into a CLUSTER (or into any other type of 
archetype, for that matter) if the need arises.

- Peter

Parser Versions

[Peter Gummer]

Oxford Partnership wrote:
 Is there a way to change the probably ought to statement to 
 something a little more definite. i.e. is there a way to formerly 
 request this and get it in to the next build ?

I've merged OPENEHR_VERSION into the ADL Parser's current release 
branch, so you can get accurate details of the parser version.

The version() function that you were calling is gone. You can now call 
out() to get a version string.

Archetype Editor's beta release isn't using this new version of the DLL 
yet. You can get it from the link half-way down the ADL Workbench 
release page:

https://wiki.oceaninformatics.com/confluence/display/TTL/ADL+Workbench+Releases

The direct link is:

http://my.openehr.org/wsvn/oe_distrib/windows/adl_parser/dotnet/?rev=0sc=0

- Peter

DLL files and licensing.

[Peter Gummer]

OxfordPartnership wrote:
 The current Archetype editor makes use of two external libraries , one
 for ADL parsing, one for XML parsing.

 What is the licence on these libraries?, can they be used in other 
 applications.
   

The XML Parser DLL is built from Archetype Editor's source code: see the 
XMLParser directory.

The ADL Parser is external, but it comes from the ADL Workbench source 
code in openEHR's ref_impl_eiffel Subversion repository.

In other words, they both belong to openEHR, and the licensing is the 
same as Archetype Editor and ADL Workbench.

- Peter

Parser Versions

[Peter Gummer]

OxfordPartnership wrote:
 This seems work and I get a version back, the version reported is :
 $LastChangedRevision: 203 $
 $LastChangedDate: 2007-04-10 05:17:40 +1000 (Tue, 10 Apr 2007) $

 As this is the parser from the latest beta release of the editor, do
 those values make sense?
   

Unfortunately, not really. That string represents the last time that the 
source file openehr_version.e was committed to the branch of the 
ref_impl_eiffel repository from which the current ADL Parser DLL is 
built. As the last change to that branch was only a month or two ago, 
sadly the so-called version string is wildly inaccurate.

There have been improvements to how this is handled in the TRUNK of the 
ref_impl_eiffel repository. We probably ought to merge those 
improvements back into the ADL Parser's current release branch, in order 
to avoid this confusion.

- Peter

Archetype Editor source code

[Peter Gummer]

Oxford Partnership wrote:
 Looking at the beta version of the archetype editor at
 https://wiki.oceaninformatics.com/confluence/display/TTL/Archetype+Editor+Beta+Release

 Can someone let me know which release this corresponds to from the
 SVN code repository.
   

http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/Nitrogen

Maybe we should mention this on the wiki page.

- Peter

Byte Order Marks

[Peter Gummer]

Adam Flinton wrote:
 So just to be certain, if a user has some existing textual content (e.g. 
 a description of some construct) in a non-UTF-8 source (e.g. a Word 
 document or HTML page) and pastes into a text area in the Archetype editor:
 A)  All  (mappable) non-UTF-8 chars would be transformed into UTF-8 chars?
 B) What about unmappable chars etc ?

 ...

 What happens wrt the Archetype editor?
   

Archetype Editor is built with standard .NET controls, which look after 
those details. It's all just standard operating system stuff. A lot of 
people from various cultures have been working with it, so this has been 
well tested.

The only bug reported in 18 months has been in a DataGrid that we're 
using, where entering a special character by keying its code on the 
numeric keypad whilst holding down the Alt key can cause the wrong 
character to appear in the wrong row.

- Peter