DV_ORDINAL C_DV_ORDINAL

On 25-06-12 14:43, David Moner wrote: > Hi Bert, > > > 2012/6/25 Bert Verhees > > > > > Hi David, is it possible that the Expand Domain Type is only in > the paid version? I don't have it in my free version. But maybe I > am wrong, but I cannot check it

DV_ORDINAL C_DV_ORDINAL

Hi Bert, 2012/6/25 Bert Verhees > > > Hi David, is it possible that the Expand Domain Type is only in the paid > version? I don't have it in my free version. But maybe I am wrong, but I > cannot check it now. I am in the wrong room/wrong computer. I will check it > later. > > > It should be ava

DV_ORDINAL C_DV_ORDINAL

> - The LinkEHR-editor does not accept OCEAN-editor constructs as > C_DV_QUANTITY, and thus, does not allow multiple constraints on a > DV_QUANTITY > > > As I explained before, LinkEHR does accept those constructs. The only > limitation is that you cannot edit them graphically (but yo

DV_ORDINAL C_DV_ORDINAL

On 25-06-12 00:51, Thomas Beale wrote: > well I think it will be best done as a proper openEHR team project, > probably in Eclipse / EMF / Ecore. The intention with the ADL > Workbench, once it is done, is to not only provide a working tool in > the interim, but to provide a set of requirements

DV_QUANTITY property (Was: DV_ORDINAL C_DV_ORDINAL)

By the way, shouldn't the 'property' of a DV_QUANTITY end up in the term_definition of a node? from the specifications, it says that must at least include 'text' and 'description', but more can be defined. For example, the specification shows: [?at4000?] = < text = <"plan">; description = <"The c

DV_ORDINAL C_DV_ORDINAL

Dear Bert, See in-line comments 2012/6/24 Bert Verhees > > - The LinkEHR-editor does not accept OCEAN-editor constructs as > C_DV_QUANTITY, and thus, does not allow multiple constraints on a > DV_QUANTITY > > As I explained before, LinkEHR does accept those constructs. The only limitation is th

DV_ORDINAL C_DV_ORDINAL

On 24/06/2012 20:49, Bert Verhees wrote: > On 24-06-12 19:47, Thomas Beale wrote: >> I would say there is no real 'market' for tools these days; everyone >> expects these kinds of tools for free. > > A free market is also a market, it serves a future vision to sell the > OpenEHR-architecture, whi

DV_ORDINAL C_DV_ORDINAL

Thanks for agreeing so much, the future looks great ;-) Bert On 24-06-12 20:30, Thomas Beale wrote: > On 24/06/2012 13:21, Bert Verhees wrote: >> Thanks, David for your answer. >> >> Excuse me my bit confusing email from yestrday, I was in a hurry >> preparing a meal for guests, and at the same

DV_ORDINAL C_DV_ORDINAL

On 24-06-12 19:47, Thomas Beale wrote: > I would say there is no real 'market' for tools these days; everyone > expects these kinds of tools for free. A free market is also a market, it serves a future vision to sell the OpenEHR-architecture, which is much harder if there is no adequate tooling.

DV_ORDINAL C_DV_ORDINAL

On 24/06/2012 13:21, Bert Verhees wrote: > Thanks, David for your answer. > > Excuse me my bit confusing email from yestrday, I was in a hurry > preparing a meal for guests, and at the same time working. > > This not about bugs but mostly about features as designed > > Although there are formal re

DV_ORDINAL C_DV_ORDINAL

On 24/06/2012 15:22, Bert Verhees wrote: > I understand the problem that is solved with the plugin types. But I > must admit, it took quite some while. > > You write that the LinkEHR cannot use the plugin types because it > follows the EN13606-2 specification, but that seems to me as a formal >

DV_ORDINAL C_DV_ORDINAL

I understand the problem that is solved with the plugin types. But I must admit, it took quite some while. You write that the LinkEHR cannot use the plugin types because it follows the EN13606-2 specification, but that seems to me as a formal reason. I wonder why this does not change to comfort

DV_ORDINAL C_DV_ORDINAL

Sorry Thomas, this email cross-mailed your replies. I wasn't looking for new emails while writing this one. Bert Op 24-6-2012 14:21, Bert Verhees schreef: > Thanks, David for your answer. > > Excuse me my bit confusing email from yestrday, I was in a hurry > preparing a meal for guests, and at

DV_ORDINAL C_DV_ORDINAL

Thanks, David for your answer. Excuse me my bit confusing email from yestrday, I was in a hurry preparing a meal for guests, and at the same time working. This not about bugs but mostly about features as designed Although there are formal reasons for the current status of the archetype-editors

DV_ORDINAL C_DV_ORDINAL

On 24/06/2012 09:45, David Moner wrote: > Dear Bert, > > I'll try to answer your questions about LinkEHR and the decision we > took when the editor was developed. All these decisions are based on > ADL & AOM 1.4 specifications, that are the ones implemented in both > LinkEHR and the Ocean archet

DV_ORDINAL C_DV_ORDINAL

Have a look at the following extract from the ordinal test archetype : SOME_TYPE[at] matches {-- root item standard_ordinal_attr matches

DV_ORDINAL C_DV_ORDINAL

Dear Bert, I'll try to answer your questions about LinkEHR and the decision we took when the editor was developed. All these decisions are based on ADL & AOM 1.4 specifications, that are the ones implemented in both LinkEHR and the Ocean archetype editor. Your first question is about dealing with

DV_ORDINAL C_DV_ORDINAL

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"] = <

DV_ORDINAL C_DV_ORDINAL

Op 23-6-2012 15:28, Peter Gummer schreef: > This seems to be the day for Archetype Editor questions ? first Pablo, and > now you:-) It was keeping me busy for some time, but Pablo inspired me to write an email, and also I was working with it now Bert

DV_ORDINAL C_DV_ORDINAL

Hi, The code-examples were not completely correct. But the issue remains The LinkEHR editor does not recognize a DV_ORDINAL made by OCEAN, and also available as, f.e. openEHR-EHR-OBSERVATION.apgar.v1.adl which I downloaded from CKM. If I make I DV_ORDINAL in LinkEHR, it looks like this ELEMENT[a

DV_ORDINAL C_DV_ORDINAL

Hi, I have some questions, I find hard to explain to my customers. See below. But first, I explain how I handle this problem, but I don't know if that is the best way. I always tell my customers to create archetypes in the LinkEHR editor, and if they want a C_DV_QUANTITY, create it by hand in a