subject:"Runtime name suggestions\?"

Re: Runtime name suggestions?

2017-01-18 Thread Ian McNicoll

Thanks Diego,

I was hoping you would confirm that.

Ian

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


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

On 17 January 2017 at 12:50, Diego Boscá <yamp...@gmail.com> wrote:

> I believe linkEHR supports this, and you can export the archetype to be
> fully compatible with AD and TD
>
> 2017-01-17 13:46 GMT+01:00 Ian McNicoll <i...@freshehr.com>:
>
>> ITEM_TREE[at0001] matches { -- Tree
>> items cardinality matches {1..*; unordered} matches {
>> CLUSTER[at0009] occurrences matches {0..1} matches { -- Flavour
>> name matches {
>> DV_TEXT matches {*}
>> DV_CODED_TEXT matches {
>> defining_code matches {
>> [local::
>> at0010, -- asdasd
>> at0011] -- asdasda
>> }
>> }
>> }
>> 
>>
>> The main issue is that though the the Archetype Editor will read that
>> construct, it loses the internal codes if the archetype is changed i.e it
>> does not write the data back out again.
>>
>> Ian
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859 <+44%207752%20097859>
>> office +44 (0)1536 414994 <+44%201536%20414994>
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>> On 17 January 2017 at 12:36, Thomas Beale <thomas.be...@openehr.org>
>> wrote:
>>
>>>
>>> It should be the same as for ADL2 except of course, stick to using the
>>> correct at-codes, i.e. 'at0004' etc, rather than id-codes. SO I think the
>>> example from the ADL 2 spec is pretty close to the one you want, with
>>> at-codes, and terminal constraints they way you want.
>>>
>>> definition
>>> ...
>>> name ∈ {
>>> DV_CODED_TEXT[id79] ∈ {
>>> defining_code ∈ {[ac1]}
>>> }
>>> DV_TEXT[id14] ∈ {
>>> value ∈ {/.+/} -- non-empty string
>>> }
>>> }
>>> ...
>>> terminology
>>> ...
>>> term_bindings = <
>>> ["snomed_ct"]= <
>>> ["ac1"] = <http://snomed.info/123456789> -- any SNOMED CT code
>>> >
>>> >
>>>
>>>
>>> - thomas
>>>
>>> On 17/01/2017 11:23, Bakke, Silje Ljosland wrote:
>>>
>>> Thanks! If I knew the syntax I could hack the ADL and test how TD
>>> handles it. J
>>>
>>>
>>>
>>> Regards,
>>> *Silje*
>>>
>>>
>>>
>>> *From:* openEHR-technical [mailto:openehr-technical-boun
>>> c...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *On
>>> Behalf Of *Ian McNicoll
>>> *Sent:* Tuesday, January 17, 2017 12:17 PM
>>> *To:* For openEHR technical discussions <openehr-technical@lists.opene
>>> hr.org> <openehr-technical@lists.openehr.org>
>>> *Subject:* Re: Runtime name suggestions?
>>>
>>>
>>>
>>> Hi Silje
>>>
>>> As Thomas has noted, it is possible in adl but is not supported in
>>> archetype editor. That is probably fixable but I'm not sure currently how
>>> template designer would handle it.
>>>
>>> Ian
>>>
>>> On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland <
>>> silje.ljosland.ba...@nasjonalikt.no> wrote:
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Runtime name suggestions?

2017-01-17 Thread Diego Boscá

I believe linkEHR supports this, and you can export the archetype to be
fully compatible with AD and TD

2017-01-17 13:46 GMT+01:00 Ian McNicoll <i...@freshehr.com>:

> ITEM_TREE[at0001] matches { -- Tree
> items cardinality matches {1..*; unordered} matches {
> CLUSTER[at0009] occurrences matches {0..1} matches { -- Flavour
> name matches {
> DV_TEXT matches {*}
> DV_CODED_TEXT matches {
> defining_code matches {
> [local::
> at0010, -- asdasd
> at0011] -- asdasda
> }
> }
> }
> 
>
> The main issue is that though the the Archetype Editor will read that
> construct, it loses the internal codes if the archetype is changed i.e it
> does not write the data back out again.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <+44%207752%20097859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 17 January 2017 at 12:36, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>>
>> It should be the same as for ADL2 except of course, stick to using the
>> correct at-codes, i.e. 'at0004' etc, rather than id-codes. SO I think the
>> example from the ADL 2 spec is pretty close to the one you want, with
>> at-codes, and terminal constraints they way you want.
>>
>> definition
>> ...
>> name ∈ {
>> DV_CODED_TEXT[id79] ∈ {
>> defining_code ∈ {[ac1]}
>> }
>> DV_TEXT[id14] ∈ {
>> value ∈ {/.+/} -- non-empty string
>> }
>> }
>> ...
>> terminology
>> ...
>> term_bindings = <
>> ["snomed_ct"]= <
>> ["ac1"] = <http://snomed.info/123456789> -- any SNOMED CT code
>> >
>> >
>>
>>
>> - thomas
>>
>> On 17/01/2017 11:23, Bakke, Silje Ljosland wrote:
>>
>> Thanks! If I knew the syntax I could hack the ADL and test how TD handles
>> it. J
>>
>>
>>
>> Regards,
>> *Silje*
>>
>>
>>
>> *From:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *On
>> Behalf Of *Ian McNicoll
>> *Sent:* Tuesday, January 17, 2017 12:17 PM
>> *To:* For openEHR technical discussions <openehr-technical@lists.opene
>> hr.org> <openehr-technical@lists.openehr.org>
>> *Subject:* Re: Runtime name suggestions?
>>
>>
>>
>> Hi Silje
>>
>> As Thomas has noted, it is possible in adl but is not supported in
>> archetype editor. That is probably fixable but I'm not sure currently how
>> template designer would handle it.
>>
>> Ian
>>
>> On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland <
>> silje.ljosland.ba...@nasjonalikt.no> wrote:
>>
>>
>>
>> ___
>> 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: Runtime name suggestions?

2017-01-17 Thread Ian McNicoll

ITEM_TREE[at0001] matches { -- Tree
items cardinality matches {1..*; unordered} matches {
CLUSTER[at0009] occurrences matches {0..1} matches { -- Flavour
name matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0010, -- asdasd
at0011] -- asdasda
}
}
}


The main issue is that though the the Archetype Editor will read that
construct, it loses the internal codes if the archetype is changed i.e it
does not write the data back out again.

Ian

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


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

On 17 January 2017 at 12:36, Thomas Beale <thomas.be...@openehr.org> wrote:

>
> It should be the same as for ADL2 except of course, stick to using the
> correct at-codes, i.e. 'at0004' etc, rather than id-codes. SO I think the
> example from the ADL 2 spec is pretty close to the one you want, with
> at-codes, and terminal constraints they way you want.
>
> definition
> ...
> name ∈ {
> DV_CODED_TEXT[id79] ∈ {
> defining_code ∈ {[ac1]}
> }
> DV_TEXT[id14] ∈ {
> value ∈ {/.+/} -- non-empty string
> }
> }
> ...
> terminology
> ...
> term_bindings = <
> ["snomed_ct"]= <
> ["ac1"] = <http://snomed.info/123456789> -- any SNOMED CT code
> >
> >
>
>
> - thomas
>
> On 17/01/2017 11:23, Bakke, Silje Ljosland wrote:
>
> Thanks! If I knew the syntax I could hack the ADL and test how TD handles
> it. J
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, January 17, 2017 12:17 PM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org> <openehr-technical@lists.openehr.org>
> *Subject:* Re: Runtime name suggestions?
>
>
>
> Hi Silje
>
> As Thomas has noted, it is possible in adl but is not supported in
> archetype editor. That is probably fixable but I'm not sure currently how
> template designer would handle it.
>
> Ian
>
> On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland <silje.ljosland.bakke@
> nasjonalikt.no> wrote:
>
>
>
> ___
> 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: Runtime name suggestions?

2017-01-17 Thread Bakke, Silje Ljosland

Thanks! If I knew the syntax I could hack the ADL and test how TD handles it. ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Tuesday, January 17, 2017 12:17 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Runtime name suggestions?

Hi Silje

As Thomas has noted, it is possible in adl but is not supported in archetype 
editor. That is probably fixable but I'm not sure currently how template 
designer would handle it.

Ian
On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
Thank you Thomas, to the extent I understand the ADL, this looks like what 
we’re looking for. How would the corresponding syntax look in ADL 1.4?

Regards,
Silje

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Thomas Beale
Sent: Tuesday, January 17, 2017 11:50 AM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Runtime name suggestions?

Hi Silje,

I'm not sure enough of the requirement, but this ADL 
logic<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_reference_model_type_refinement>
 may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before the 
following heading after that section.
The basic logic of this is described 
here<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_narrowed_subtype_constraints>.

Although these are references from ADL2, they should apply in ADL 1.4 as well.

- thomas
On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:
Hi,

We’re trying to finalise the pattern for exclusion archetypes, and would like 
to use the element names to carry some flavor differences such as “no known 
history of …” and “no evidence of …”. We’ve considered adding a runtime name 
constraint to make some level of standardization of these statements, but at 
the same time we recognize that there will be considerable variation in what 
will be required as statements in different use cases. So what we’d like to do 
is to use a kind of “optional runtime name constraint”, or “runtime name 
suggestion”. We know this isn’t supported by tooling atm, but is it allowed by 
the specs? If so, how can it be done?

Kind regards,
Silje Ljosland Bakke

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

Re: Runtime name suggestions?

2017-01-17 Thread Ian McNicoll

Hi Silje

As Thomas has noted, it is possible in adl but is not supported in
archetype editor. That is probably fixable but I'm not sure currently how
template designer would handle it.

Ian
On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Thank you Thomas, to the extent I understand the ADL, this looks like what
> we’re looking for. How would the corresponding syntax look in ADL 1.4?
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Thomas Beale
> *Sent:* Tuesday, January 17, 2017 11:50 AM
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: Runtime name suggestions?
>
>
>
> Hi Silje,
>
> I'm not sure enough of the requirement, but this ADL logic
> <http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_reference_model_type_refinement>
> may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before
> the following heading after that section.
>
> The basic logic of this is described here
> <http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_narrowed_subtype_constraints>
> .
>
> Although these are references from ADL2, they should apply in ADL 1.4 as
> well.
>
> - thomas
>
> On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:
>
> Hi,
>
>
>
> We’re trying to finalise the pattern for exclusion archetypes, and would
> like to use the element names to carry some flavor differences such as “no
> known history of …” and “no evidence of …”. We’ve considered adding a
> runtime name constraint to make some level of standardization of these
> statements, but at the same time we recognize that there will be
> considerable variation in what will be required as statements in different
> use cases. So what we’d like to do is to use a kind of “optional runtime
> name constraint”, or “runtime name suggestion”. We know this isn’t
> supported by tooling atm, but is it allowed by the specs? If so, how can it
> be done?
>
>
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
>
> ___
> 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: Runtime name suggestions?

2017-01-17 Thread Bakke, Silje Ljosland

Thank you Thomas, to the extent I understand the ADL, this looks like what 
we're looking for. How would the corresponding syntax look in ADL 1.4?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Tuesday, January 17, 2017 11:50 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Runtime name suggestions?

Hi Silje,

I'm not sure enough of the requirement, but this ADL 
logic<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_reference_model_type_refinement>
 may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before the 
following heading after that section.
The basic logic of this is described 
here<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_narrowed_subtype_constraints>.

Although these are references from ADL2, they should apply in ADL 1.4 as well.

- thomas
On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:
Hi,

We're trying to finalise the pattern for exclusion archetypes, and would like 
to use the element names to carry some flavor differences such as "no known 
history of ..." and "no evidence of ...". We've considered adding a runtime 
name constraint to make some level of standardization of these statements, but 
at the same time we recognize that there will be considerable variation in what 
will be required as statements in different use cases. So what we'd like to do 
is to use a kind of "optional runtime name constraint", or "runtime name 
suggestion". We know this isn't supported by tooling atm, but is it allowed by 
the specs? If so, how can it be done?

Kind regards,
Silje Ljosland Bakke

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

Re: Runtime name suggestions?

2017-01-17 Thread Thomas Beale


Hi Silje,

I'm not sure enough of the requirement, but this ADL logic 
 
may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just 
before the following heading after that section.


The basic logic of this is described here 
.


Although these are references from ADL2, they should apply in ADL 1.4 as 
well.


- thomas

On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:


Hi,

We’re trying to finalise the pattern for exclusion archetypes, and 
would like to use the element names to carry some flavor differences 
such as “no known history of …” and “no evidence of …”. We’ve 
considered adding a runtime name constraint to make some level of 
standardization of these statements, but at the same time we recognize 
that there will be considerable variation in what will be required as 
statements in different use cases. So what we’d like to do is to use a 
kind of “optional runtime name constraint”, or “runtime name 
suggestion”. We know this isn’t supported by tooling atm, but is it 
allowed by the specs? If so, how can it be done?


Kind regards,
*Silje Ljosland Bakke*

**



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

Runtime name suggestions?

2017-01-16 Thread Bakke, Silje Ljosland

Hi,

We're trying to finalise the pattern for exclusion archetypes, and would like 
to use the element names to carry some flavor differences such as "no known 
history of ..." and "no evidence of ...". We've considered adding a runtime 
name constraint to make some level of standardization of these statements, but 
at the same time we recognize that there will be considerable variation in what 
will be required as statements in different use cases. So what we'd like to do 
is to use a kind of "optional runtime name constraint", or "runtime name 
suggestion". We know this isn't supported by tooling atm, but is it allowed by 
the specs? If so, how can it be done?


Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Re: Runtime name suggestions?

Re: Runtime name suggestions?

Re: Runtime name suggestions?

RE: Runtime name suggestions?

Re: Runtime name suggestions?

RE: Runtime name suggestions?

Re: Runtime name suggestions?

Runtime name suggestions?

8 matches

Site Navigation

Mail list logo

Footer information