Re: definition of custom fields in archetypes

Hi Georg, Yes that is absolutely correct. The archetypes act as a constraint on the RM so must always be compliant with the RM, and whatever underlying archetype class is selected. Same applies to templates. Practically speaking this does still give us a huge amount of flexibility, especially

definition of custom fields in archetypes

Hallo, I have a question about the degree of freedom in defining archetypes: Archetypes are not composed but rather specified by constraining the base classes from the reference model. Hence no new/custom field members can be definied in the definition of a new archetype but only the field

Re: AQL access of fields of potential subclasses or derived archetypes

esses this field with the assumption that the field is of type EHR_STATUS. I have written a type checker for AQL queries, so I am now stumbling across queries that access fields of potential subclasses or derived archetypes. Does/should the specification generally allow such a thing ? Greetings G

Re: AQL access of fields of potential subclasses or derived archetypes

) that accesses this field with the >> assumption that the field is of type EHR_STATUS. >> I have written a type checker for AQL queries, so I am now stumbling >> across queries that access fields of potential subclasses or derived >> archetypes. >> Does/should the specificat

Re: AQL access of fields of potential subclasses or derived archetypes

gt; example (chapter 3.7.2.3. NOT) that accesses this field with the > assumption that the field is of type EHR_STATUS. > I have written a type checker for AQL queries, so I am now stumbling > across queries that access fields of potential subclasses or derived > archetypes. > Does/should the

AQL access of fields of potential subclasses or derived archetypes

e (chapter 3.7.2.3. NOT) that accesses this field with the assumption that the field is of type EHR_STATUS. I have written a type checker for AQL queries, so I am now stumbling across queries that access fields of potential subclasses or derived archetypes. Does/should the specification gener

Re: Rules in archetypes - what are the requirements?

From: openEHR-technical on behalf of Thomas Beale Reply-To: For openEHR technical discussions Date: Saturday, 2 February 2019 at 20:10 To: "openehr-technical@lists.openehr.org" Subject: Re: Rules in archetypes - what are the requirements? On 02/02/2019 16:21, Pieter Bos wr

Re: Rules in archetypes - what are the requirements?

On 02/02/2019 16:21, Pieter Bos wrote: *From: *openEHR-technical on behalf of Thomas Beale *Reply-To: *For openEHR technical discussions *Date: *Saturday, 2 February 2019 at 15:01 *To: *"openehr-technical@lists.openehr.org" *Subject: *Re: Rules in archety

Re: Rules in archetypes - what are the requirements?

From: openEHR-technical on behalf of Thomas Beale Reply-To: For openEHR technical discussions Date: Saturday, 2 February 2019 at 15:01 To: "openehr-technical@lists.openehr.org" Subject: Re: Rules in archetypes - what are the requirements? Assuming you meant to put 'id7' as the

Re: Rules in archetypes - what are the requirements?

t; Date: Friday, 1 February 2019 at 14:16 To: "openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>" mailto:openehr-technical@lists.openehr.org>> Subject: Re: Rules in archetypes - what are the requirements? Thanks Pieter, this is very useful. On

Re: Rules in archetypes - what are the requirements?

On 02/02/2019 13:15, Ian McNicoll wrote: Hi Pieter, "But why would I need a function to calculate a score that is just a sum of a number of values, instead of a few +-operators?" It is an open question but one advantage of using the function approach, with simple values is that it can

Re: Rules in archetypes - what are the requirements?

r just the statically defined members in the archetype - which can also be multiple, e.g. see the Apgar archetype, it has 1 min, 2 min, 5 min events? Normally we want the processing of 'rules' expressions in archetypes to apply to the data when the archetype is being used in its normal role of cr

Re: Rules in archetypes - what are the requirements?

ements. I’m not sure how to do that with > data binding. > > > > Regards, > > > Pieter Bos > > > > *From: *openEHR-technical > on behalf of Thomas Beale > *Reply-To: *For openEHR technical discussions < > openehr-technical@lists.openehr.org> &g

Re: Rules in archetypes - what are the requirements?

: openEHR-technical on behalf of Thomas Beale Reply-To: For openEHR technical discussions Date: Friday, 1 February 2019 at 14:16 To: "openehr-technical@lists.openehr.org" Subject: Re: Rules in archetypes - what are the requirements? Thanks Pieter, this is very useful. On 01/02/201

Re: Rules in archetypes - what are the requirements?

t current requirements, working solutions, workaround etc, the better - the intention is to evolve the expression facility in archetypes to match those needs and to be as useful as possible. - thomas ___ openEHR-technical mailing list openEHR-

Re: Rules in archetypes - what are the requirements?

, this will be different for different implementations. Regards, Pieter Bos From: openEHR-technical on behalf of Thomas Beale Reply-To: For openEHR technical discussions Date: Friday, 1 February 2019 at 13:01 To: Openehr-Technical Subject: Rules in archetypes - what are the requirements? For many

Re: Rules in archetypes - what are the requirements?

ta item 'tobacco use' /= at44|non-user|. > > This also is not that easy to read, or clear in its intentions. > > More recently, as part of the development of a simple expression language > that can be used across openEHR (archetypes, Task Planning, GDL etc), I > proposed some key improv

Rules in archetypes - what are the requirements?

. More recently, as part of the development of a simple expression language that can be used across openEHR (archetypes, Task Planning, GDL etc), I proposed some key improvements to expressions in archetypes, namely: * symbolic names for paths, done by bindings * an explicit 'check

RE: Syntax for including archetypes in SLOTs, regardless of version

for including archetypes in SLOTs, regardless of version Hi everyone, In our modelling, it is safe to assume that the latest version of an archetype is the best candidate on offer for anyone using an archetype and filling a SLOT for the first time. Options for use of previous versions may

RE: Syntax for including archetypes in SLOTs, regardless of version

behind it, not unreasonably, that as long as no archetypes (and versions) are excluded in a specific way, even if the SLOT suggests a v0 as an inclusion, it technically doesn’t stop a v1 being inserted in there. So the inclusion of all versions also has an important design guidance function as well

AW: AW: Syntax for including archetypes in SLOTs, regardless of version

Von: openEHR-technical Im Auftrag von Thomas Beale Gesendet: Dienstag, 18. Dezember 2018 18:39 An: openehr-technical@lists.openehr.org Betreff: Re: AW: Syntax for including archetypes in SLOTs, regardless of version The example below openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_

Re: AW: Syntax for including archetypes in SLOTs, regardless of version

On 18/12/2018 16:48, Sebastian Garde wrote: Hi Silje, hi Thomas, hi all, Whether the CKM validation errors from below are correct or bogus boils down to my question from before whether it is valid or not to just leave the version part out completely. In my understanding the regex needs to

AW: Syntax for including archetypes in SLOTs, regardless of version

\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few. A few archetypes in CKM (demographics mainly I think) have shortened this further to omit the openEHR-EHR- prefix. This currently turns up as a validation error in CKM as well

RE: Syntax for including archetypes in SLOTs, regardless of version

will stay the same (or it should have a completely new ID). We don’t generally include archetypes based on their specific content at the time of inclusion, but on the clinical concept they represent. If leaving the version part out completely is the correct way to leave versioning open when

Re: Syntax for including archetypes in SLOTs, regardless of version

For reference, these are the various regexes I use in the ADL workbench . ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: Syntax for including archetypes in SLOTs, regardless of version

On Tue, Dec 18, 2018 at 01:17:38PM +0100, Karsten Hilbert wrote: > > In other words, add a pattern to catch “any single (possibly double) digit > > version number” (?). > > \d{1,2} Ah, sorry, was misled by *number*. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

Re: Syntax for including archetypes in SLOTs, regardless of version

\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2) or openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] to allow any version, just leave the version id part off entirely. Note that different major versions of an archetype are technically different archetypes - i.e. they contain some breaking

Re: Syntax for including archetypes in SLOTs, regardless of version

On Tue, Dec 18, 2018 at 12:09:56PM +, Bakke, Silje Ljosland wrote: > In other words, add a pattern to catch “any single (possibly double) digit > version number” (?). \d{1,2} Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

RE: Syntax for including archetypes in SLOTs, regardless of version

v[0-9][0-9] would also include v00-v09, which we don’t want. Regards, Silje From: openEHR-technical On Behalf Of Anastasiou A. Sent: Tuesday, December 18, 2018 1:04 PM To: For openEHR technical discussions Subject: RE: Syntax for including archetypes in SLOTs, regardless of version Hi Silje

RE: Syntax for including archetypes in SLOTs, regardless of version

-OBSERVATION\.body_mass_index”. All the best Athanasios Anastasiou From: openEHR-technical On Behalf Of Bakke, Silje Ljosland Sent: 18 December 2018 11:57 To: For openEHR technical discussions Subject: Syntax for including archetypes in SLOTs, regardless of version Hi, Sebastian Garde and I had

Syntax for including archetypes in SLOTs, regardless of version

Hi, Sebastian Garde and I had a brainstorm a while ago about how to handle inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be noted explicitly (whether because of tooling

Re: Reference Model as Archetypes ?

rser to support more things, but the archetype creation is completely RM driven (archetypes created with LinkEHR are always compliant with the RM you choose). That created archetype can be then saved to different representations depending of your needs (ADL for specific tools, XML,

Re: Reference Model as Archetypes ?

We plan in using Archie library when we migrate our tools for ADL2 :) El mié., 12 dic. 2018 15:24, Thomas Beale escribió: > You can always check conformance with the ADL Workbench, it will consume > ADL1.4 and ADL2. And Archie now produces the same regression results as > ADL WB, so it could be

Re: Reference Model as Archetypes ?

type creation is completely RM driven (archetypes created with LinkEHR are always compliant with the RM you choose). That created archetype can be then saved to different representations depending of your needs (ADL for specific tools, XML, etc). Regards El mié., 12 dic. 2018 15:09, Bert Verhees escr

Re: Reference Model as Archetypes ?

You can always check conformance with the ADL Workbench, it will consume ADL1.4 and ADL2. And Archie now produces the same regression results as ADL WB, so it could be used as well, and in future, will probably become the main reference tool. - thomas

Re: Reference Model as Archetypes ?

. There are tools that don't comply with this general ADL, and we provided an export version of archetypes that produces a modified version of the ADL syntax that other older and not maintained tools can parse. If you want to call this subset "official archetypes" be my guest. The word

Re: Reference Model as Archetypes ?

with this general ADL, and we provided an export version of archetypes that produces a modified version of the ADL syntax that other older and not maintained tools can parse. If you want to call this subset "official archetypes" be my guest. El mié., 12 dic. 2018 a las 14:28, Bert Verhees (

Re: Reference Model as Archetypes ?

On 12-12-18 13:48, Diego Boscá wrote: The official one, these are 'hacks' that allow you to handle requirements and edge cases only present in these RM archetypes Diego, I don't want to be harsh about LinkEhr, which is a very strong product. But this situation raises questions. I already had

Re: Reference Model as Archetypes ?

I don't think they are currently generated, but you can generate them if you reimport the model and select them El mié., 12 dic. 2018 a las 13:44, Georg Fette (< georg.fe...@uni-wuerzburg.de>) escribió: > Hello, > In the LinkEHR files the archetypes for the "EHR Infomation Model

Re: Reference Model as Archetypes ?

The official one, these are 'hacks' that allow you to handle requirements and edge cases only present in these RM archetypes El mié., 12 dic. 2018 a las 13:41, Bert Verhees () escribió: > On 12-12-18 12:53, Diego Boscá wrote: > > We used that one as a basis and generalized mostly

Re: Reference Model as Archetypes ?

.fe...@uni-wuerzburg.de>) escribió: > Hi Diego, > Yes, if you have a working parser for those archetypes that would be > useful. The modified grammer would also be useful. > What are the copyright constraints on your parser and your grammmer file ? > I managed to get one of

Re: Reference Model as Archetypes ?

Hello, In the LinkEHR files the archetypes for the "EHR Infomation Model" are contained (ACTION, CLUSTER, etc.). Are there also somewhere archetypes that describe the "Data Types Information Model" (e.g. DV_QUANTITY, DV_MEDIA, etc

Re: Reference Model as Archetypes ?

On 12-12-18 12:53, Diego Boscá wrote: We used that one as a basis and generalized mostly to allow the special RM 'at' codes we created. I can send you the modified grammar or the parser if you want. Wouldn't that disturb interoperability processes? One could wonder: Which one is the right

Re: Reference Model as Archetypes ?

Hi Diego, In the Archetypes contained in the LinkEHR files I am missing the subclasses that are subclassed by the root archetypes. In ACTION for example the subclass INSTRUCTION_DETAILS is used. This is used in the ACTION.adl file and it is parseable but I wonder

Re: Reference Model as Archetypes ?

Hi Diego, Yes, if you have a working parser for those archetypes that would be useful. The modified grammer would also be useful. What are the copyright constraints on your parser and your grammmer file ? I managed to get one of the archetypes parsed by lowercasing the language codes

Re: Reference Model as Archetypes ?

rse the .adl files from LinkEHR and got several > Exceptions. I currently use the adl-parser from > org.openehr.java-libs_v_1.0.71. > Which parser can I use to parse those archetypes ? > Greetings > Georg > > -- > --

Re: Reference Model as Archetypes ?

Hi Diego, I just tried to parse the .adl files from LinkEHR and got several Exceptions. I currently use the adl-parser from org.openehr.java-libs_v_1.0.71. Which parser can I use to parse those archetypes ? Greetings Georg

Re: Reference Model as Archetypes ?

y imported). As they are archetypes from these classes on the demographic archetypes of CKM, the classes were selected as archetypable in the RM import process, and thus generated. They should virtually equivalent (apart from changes in the archetype identifier). El mié., 12 dic. 2018 a las 12:21, G

Re: Reference Model as Archetypes ?

Hi Diego, Thank you, that is exactly what I was looking for. In the DEMOGRAPHICS and the EHR package there are 6 archetypes which have the same name but differ only in their full path name: CLUSTER, ELEMENT, ITEM_LIST, ITEM_SINGLE, ITEM_TABLE and ITEM_TREE. Why are they two versions of those

Re: Reference Model as Archetypes ?

But in this case the archetype you create couldn't be use for validation purposes. I think I'm not fully understanding what you mean with this El mar., 11 dic. 2018 a las 12:37, Thomas Beale () escribió: > I think this is more or less the same as a kind of archetype with no codes > at all, only

Re: Reference Model as Archetypes ?

I think this is more or less the same as a kind of archetype with no codes at all, only containing RM elements. I was expecting something more like: CLASS [Observation_code] matches {     attributes matches {     ATTRIBUTE [Observation_data_code] matches {     name matches {"data"}

Re: Reference Model as Archetypes ?

As an example, this is the Observation archetype https://pastebin.com/WhehexLR El mar., 11 dic. 2018 a las 11:53, Diego Boscá () escribió: > It is basically AOM, serialized as ADL files > > El mar., 11 dic. 2018 a las 11:51, Thomas Beale () > escribió: > >> Diego, >> >> what do you use as the

Re: Reference Model as Archetypes ?

It is basically AOM, serialized as ADL files El mar., 11 dic. 2018 a las 11:51, Thomas Beale () escribió: > Diego, > > what do you use as the underlying information model in that case? > Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc? > > - thomas > > On 11/12/2018

Re: Reference Model as Archetypes ?

Diego, what do you use as the underlying information model in that case? Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc? - thomas On 11/12/2018 09:40, Diego Boscá wrote: Hi Georg, That's exactly how we define reference models with LinkEHR. We generated them from

Re: Reference Model as Archetypes ?

download LinkEHR and get them from there. Regards El mar., 11 dic. 2018 a las 10:20, Georg Fette (< georg.fe...@uni-wuerzburg.de>) escribió: > Hello, > Is there somewere a machine readable definition available which > describes the content of the openEHR Reference Mode

Reference Model as Archetypes ?

Hello, Is there somewere a machine readable definition available which describes the content of the openEHR Reference Model as Archetypes ? The Reference Model classes should be expressable as Archetypes, shouldn't they ? At least concerning their logical data model. The methods they also

Re: Parsing of Archetypes/Templates

On 12-11-18 18:40, Bert Verhees wrote: >> Another very important restriction for using XML Schema, in my opinion, >> is that you cannot have two or more elements with the same name but a >> different data type. This data type must be in detail the same. XML Schema >> regards an Element with a

Re: Parsing of Archetypes/Templates

purpose. this already works (for nearly 10 years) and it validates against the XML schema standard. What it doesn't do is validate everything you want to validate, i.e. not all things in the archetypes. But it's good enough most of the time. I am in the proud possession of the book

Re: Parsing of Archetypes/Templates

), which can be used to validate JSON OpenEhr-datasets against archetypes/templates. I wrote an AOM(OpenEhr/CEN13606)-Schematron-validation-generator years ago, exactly for this reason, I must have the sourcecode somewhere. Good for Marand to have validation too, because checking data-sets before

Re: Parsing of Archetypes/Templates

10 years) and it validates against the XML schema standard. What it doesn't do is validate everything you want to validate, i.e. not all things in the archetypes. But it's good enough most of the time. To do things properly, I agree, you would probably use Schematron + XSD, or personally I

Re: Parsing of Archetypes/Templates

On 12/11/2018 09:44, Bert Verhees wrote: Sorry, I first replied to Pieter Bos only, now to the list. Pieter already replied to me that the question was not about XSD to check datasets was . So, read my reply, for those interested in easy validating datasets: It is possible to have an XSD

Re: Parsing of Archetypes/Templates

Yes, https://github.com/openEHR/java-libs works for ADL 1.4. If you want the latest and newest, ADL 2 is the way to go. You can convert the archetypes to ADL 2 using the ADL workbench and they will parse with Archie. The workbench can be found at http://www.openehr.org. If you want

Re: Parsing of Archetypes/Templates

Hello Georg, Archie is meant to be used with ADL2 archetypes, if you want to parse 1.4 archetypes I think java implementation you mentioned before is your current best option. Regards El lun., 12 nov. 2018 a las 13:40, Georg Fette (< georg.fe...@uni-wuerzburg.de>) escribió: >

Re: Parsing of Archetypes/Templates

Hi Peter, The Archie-Toolkit looks promising. I tried to parse one of the archetypes from the CKM (BloodPressure) and tried to parse the exported ADL. However, I got a Exception when trying this because the exported ADL does not seem to be parseable: line 1:24 mismatched input '1.4' expecting

Re: Parsing of Archetypes/Templates

an XSD to describe an archetype and check a dataset with it. Archetypes can have logical constructs which are not allowed in XSD. It has to do with elements with the same name on the same level, that is not allowed in XSD, even not when there are different attributes. You can use Schematron

Re: Parsing of Archetypes/Templates

Hello George, If you are looking for something to handle ADL 2 archetypes - the most recent version -, have a look at https://github.com/opener/archie . It is a java library that can parse archetypes, flatten and validate them, create operational templates and more. Are you using

Parsing of Archetypes/Templates

Hello, For a project we want to create a generic mechanism to transform archetypes into FHIR Logical Models, so we can store, retrieve and query archetype instance with FHIR tools (CQL, FHIR-REST-API-query). At the moment we just want to read/write archetypes and not archetype instances. We

Re: Extract archetypes

Note that for class and property names, we tend to stick to typical programming convantions, which is * class - first letter capital * property / method name - first letter lower-case One reason to do this is to be able to distinguish a class name on its own, e.g. in an ADL archetype, and

Re: Extract archetypes

I agree about the case insensitivity. Archie still does this case sensitive, so I just created https://github.com/openEHR/archie/issues/8 ( Pieter On 30/11/2017, 15:23, "openEHR-technical on behalf of Thomas Beale"

Re: Extract archetypes

On 30-11-17 15:23, Thomas Beale wrote: I think the string matching should be case-insensitive, and the current regexes allow for any case. Various tools implementers would need to check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc. This is like Diego and Pieter also

Re: Extract archetypes

I think the string matching should be case-insensitive, and the current regexes allow for any case. Various tools implementers would need to check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc. - thomas On 30/11/2017 13:55, Bert Verhees wrote: So, there are also

Re: Extract archetypes

0> shows that underscores are accepted as well. I would suggest using the proper specification name as various tools are starting to depend on consistent use of names across specifications, UML packages and classes, and archetypes. In fact I suspect that right now the ADL Workbench would not recognise

Re: Extract archetypes

pecifications, UML packages and classes, and archetypes. In fact I suspect that right now the ADL Workbench would not recognise an Extract archetype that didn't have EHR_EXTRACT as the RM class qualifier, because the relevant BMM <https://github.com/openEHR/reference-models/tree/master/models/

Re: Extract archetypes

nsistent use of names across specifications, UML packages and classes, and archetypes. In fact I suspect that right now the ADL Workbench would not recognise an Extract archetype that didn't have EHR_EXTRACT as the RM class qualifier, because the relevant BMM <https://github.com/openEHR/refere

Re: Extract archetypes

l discussions <openehr-technical@lists.openehr.org <mailto:openehr-technical@lists.openehr.org>> Date: Thursday, 30 November 2017 at 13:06 To: For openEHR technical discussions <openehr-technical@lists.openehr.org <mailto:openehr-technical@lists.openehr.org&

Re: Extract archetypes

> behalf of Diego Boscá <yamp...@gmail.com> > Reply-To: For openEHR technical discussions <openehr-technical@lists. > openehr.org> > Date: Thursday, 30 November 2017 at 13:06 > To: For openEHR technical discussions <openehr-technical@lists.openehr.org > > &g

Re: Extract archetypes

On 30-11-17 13:06, Diego Boscá wrote: Having said that, I'm not sure current regex for archetype ids allows the use of spaces or undescores on the rm part. I'll have to check that I was too fast with my compliments ;-) In that case, we can leave the underscore out, It remains readable. Bert

Re: Extract archetypes

sts.openehr.org> Date: Thursday, 30 November 2017 at 13:06 To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Subject: Re: Extract archetypes Having said that, I'm not sure current regex for archetype ids allows the use of spaces or undescores on the rm part. I'll hav

Re: Extract archetypes

Thanks Diego, that seems a good suggestion based on good reasoning. Bert On 30-11-17 13:04, Diego Boscá wrote: Hi Bert, I would say that the "rm name" would be "EHR_Extract", as it is the way the package is called in the documentation

Re: Extract archetypes

Having said that, I'm not sure current regex for archetype ids allows the use of spaces or undescores on the rm part. I'll have to check that 2017-11-30 9:04 GMT-03:00 Diego Boscá : > Hi Bert, > > I would say that the "rm name" would be "EHR_Extract", as it is the way > the

Re: Extract archetypes

Hi Bert, I would say that the "rm name" would be "EHR_Extract", as it is the way the package is called in the documentation http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that demographics and EHR are the other package names). After that you would put the

Extract archetypes

Hi, Since that it is so that some extract-classes derive from Locatable, they can be used to use them as RM-class for an archetype-definition. But how would the ArchetypeId look like, special the rmName. Would it be something like openEHR-Extract-Extract ? Thanks in advance for

Re: Including reference range in archetypes

gt; I would expect a UI to colour-code each component in a similar fashion, to > indicate potential risk. > > You might want to explore GDL, which is an extension to openEHR that acts > as a glue layer between archetypes and those sort of rules. > > http://www.openehr.org/releases/CD

Re: Including reference range in archetypes

is an extension to openEHR that acts as a glue layer between archetypes and those sort of rules. http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html There is also some interest in folding aspects of GDL inside archetypes as part of the 'rules' aspect of ADL. One of the barriers to getting this working

Including reference range in archetypes

Hi, I am trying to create an archetype that screens for health risks. All the questions have ordinal data. Based on the values selected for the questions, the consolidate risk value is calculated. I want the UIi to display appropriate warnings (coloring the risk value etc) based on a reference

Re: inheritance of archetypes

d you’re looking for a java library for your > EHR or authoring tools, Archie implements ADL-2 and the reference model, > plus a lot of tools for working with them. > Important for specialization: It include a flattener and operational > template creator that converts specialized ar

Re: inheritance of archetypes

e have better tools. > > If you want to use ADL-2 and you’re looking for a java library for your > EHR or authoring tools, Archie implements ADL-2 and the reference model, > plus a lot of tools for working with them. > Important for specialization: It include a flattener and operational

Re: inheritance of archetypes

authoring tools, Archie implements ADL-2 and the reference model, > plus a lot of tools for working with them. > Important for specialization: It include a flattener and operational > template creator that converts specialized archetypes and templates to an > operational template. Those make

Re: inheritance of archetypes

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

Re: inheritance of archetypes

, Archie implements ADL-2 and the reference model, plus a lot of tools for working with them. Important for specialization: It include a flattener and operational template creator that converts specialized archetypes and templates to an operational template. Those make working with specialized

Re: inheritance of archetypes

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

Re: inheritance of archetypes

On 01/03/2017 10:00, Bert Verhees wrote: Op 1-3-2017 om 10:44 schreef Thomas Beale: Good news Thomas, but don't bring it with disdain. I don't know what the words means ;) I got it from google translate, in French it is dedain. c'était une blague... that appears to be a PR about

Re: inheritance of archetypes

Hi Bert, Marand are about to release a major interim update to their ADL-2 Archetype tooling. I am told sometime in March). One of the major design criteria is to be able to create ADL1.4 artefacts and, critically, ADL 1.4 .opts so we can use the new tools with existing systems, but take

Re: inheritance of archetypes

Op 1-3-2017 om 10:44 schreef Thomas Beale: Good news Thomas, but don't bring it with disdain. I don't know what the words means ;) I got it from google translate, in French it is dedain. that appears to be a PR about GDL? I meant a current list of Open Issues, I don't know why the 168 is

Re: inheritance of archetypes

we may be able to re-use ideas from the Intermountain Healthcare Activity-Based Design (ABD) project I am working on in the US, which includes presentation specification in its archetypes (they are not ADL archetypes, but something similar). On 01/03/2017 09:26, Anastasiou A. wrote

Re: inheritance of archetypes

but don't bring it as it is like a breathe, then you disregard the hard work of people working on the technical information side of institutions. Well the tooling that is there now is: * ADL Workbench, which will transform any set of ADL 1.4 archetypes to ADL2 differential form, and gene

Re: inheritance of archetypes

Good news Thomas, but don't bring it with disdain. Op 1-3-2017 om 10:15 schreef Thomas Beale: which when they are read into ADL Workbench, are re-engineered into differential form I think the ADL Workbench is a cryptic piece of software which could use some GUI-specialists to redesign it, so

RE: inheritance of archetypes

Sent: 01 March 2017 09:15 To: openehr-technical@lists.openehr.org Subject: Re: inheritance of archetypes On 01/03/2017 09:03, Bert Verhees wrote: Dear all of the technical mailing list, I made a new message tothis list (specialized ;-), so it will be discussed separately. I do that because

Re: inheritance of archetypes

mented in the ADL Workbench, and more recently in the ADL-designer project <https://github.com/openEHR/adl-designer>. it works just like an OO programming language. There are dozens of examples in the test archteypes <https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/featu

Re: inheritance of archetypes

works just like an OO programming language. There are dozens of examples in the test archteypes <https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>, and also in the CKM archetypes, which when they are read into ADL Workbench, are re-engineered into differentia

  1   2   3   4   5   6   >