Re: Runtime name suggestions?

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

> 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 
> 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"] =  -- 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 ] *On
>> Behalf Of *Ian McNicoll
>> *Sent:* Tuesday, January 17, 2017 12:17 PM
>> *To:* For openEHR technical discussions > hr.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?

[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  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"] =  -- 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 ] *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, January 17, 2017 12:17 PM
> *To:* For openEHR technical discussions  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  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: Use of RM:provider

[Ian McNicoll]

Hi Thomas,

I'm not convinced as yet that this is a universally useful requirement,
particularly as we carry much of this source/ provenance metadata already.

@Silje - are the GPs expected to add this extra information to every Entry
in the summary? That seems like a significant burden, and actually in many
cases unknowable.

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:34, Thomas Beale  wrote:

>
> Ideally there would be one or more classifiers at the ENTRY level,
> something that does not exist today. There are some others that we will
> include, e.g. relating to epistemic_status.
>
> I would follow Ian's suggestion on the extension slot; it may be that the
> coding recorded there may need to be adjusted to a new place in relevant
> archetypes later on. Not ideal, but not a big problem either, assuming they
> are not used to create data before that is done.
>
> Ian - do we have a related PR mooted for RM Release-1.0.4?
>
> - thomas
>
> On 17/01/2017 11:22, Bakke, Silje Ljosland wrote:
>
> Thank you Thomas and Ian!
>
>
>
> This is indeed a national requirement, and one where we do need to
> represent the chosen value in a coded text element. The background here is
> an entry in the critical information part of the national summary record,
> ie an adverse reaction, complication from anaesthesia, critical condition,
> ongoing treatment, implant, change of treatment routine, or infection. Each
> of these will be either an EVALUATION.adverse_reaction_risk,
> EVALUATION.problem_diagnosis, or EVALUATION.precaution. The patient’s GP
> normally records the information, and this code set is supposed to be used
> to specify where the GP got the information about each of the entries from.
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org ] *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, January 17, 2017 11:36 AM
> *To:* For openEHR technical discussions  openehr.org> 
> *Subject:* Re: Use of RM:provider
>
>
>
> Hi Silje,
>
>
>
> I would agree with your and Thomas's assessment. This codeset does not
> really fit with provider, or indeed with any other RM attributes, although
> many but not all of these items could be calculated/ derived from existing
> attributes.
>
>
>
> I guess this is part of a national requirement, and is a similar issue to
> the one we faced in Sweden, where the V-TIM standard was largely aligned
> with openEHR but had some extra specific metadata around Contsys-2 that
> needed to be captured.
>
>
>
> This was exactly the purpose for the Extension slot that we are adding to
> new archetypes, so that would be my suggestion. Having said that, I do
> wonder about the purpose of this data -where is the value, over and above
> what is already captured by native openEHR RM. This feels like largely a
> derived set of data for reporting purposes
>
> e,g,
>
>
>
> ___
> 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: Use of RM:provider

[Thomas Beale]

Ideally there would be one or more classifiers at the ENTRY level, 
something that does not exist today. There are some others that we will 
include, e.g. relating to epistemic_status.


I would follow Ian's suggestion on the extension slot; it may be that 
the coding recorded there may need to be adjusted to a new place in 
relevant archetypes later on. Not ideal, but not a big problem either, 
assuming they are not used to create data before that is done.


Ian - do we have a related PR mooted for RM Release-1.0.4?

- thomas


On 17/01/2017 11:22, Bakke, Silje Ljosland wrote:


Thank you Thomas and Ian!

This is indeed a national requirement, and one where we do need to 
represent the chosen value in a coded text element. The background 
here is an entry in the critical information part of the national 
summary record, ie an adverse reaction, complication from anaesthesia, 
critical condition, ongoing treatment, implant, change of treatment 
routine, or infection. Each of these will be either an 
EVALUATION.adverse_reaction_risk, EVALUATION.problem_diagnosis, or 
EVALUATION.precaution. The patient’s GP normally records the 
information, and this code set is supposed to be used to specify where 
the GP got the information about each of the entries from.


Regards,
*Silje*

*From:*openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org] *On Behalf Of 
*Ian McNicoll

*Sent:* Tuesday, January 17, 2017 11:36 AM
*To:* For openEHR technical discussions 


*Subject:* Re: Use of RM:provider

Hi Silje,

I would agree with your and Thomas's assessment. This codeset does not 
really fit with provider, or indeed with any other RM attributes, 
although many but not all of these items could be calculated/ derived 
from existing attributes.


I guess this is part of a national requirement, and is a similar issue 
to the one we faced in Sweden, where the V-TIM standard was largely 
aligned with openEHR but had some extra specific metadata around 
Contsys-2 that needed to be captured.


This was exactly the purpose for the Extension slot that we are adding 
to new archetypes, so that would be my suggestion. Having said that, I 
do wonder about the purpose of this data -where is the value, over and 
above what is already captured by native openEHR RM. This feels like 
largely a derived set of data for reporting purposes


e,g,



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

RE: Runtime name suggestions?

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

RE: Use of RM:provider

[Bakke, Silje Ljosland]

Thank you Thomas and Ian!

This is indeed a national requirement, and one where we do need to represent 
the chosen value in a coded text element. The background here is an entry in 
the critical information part of the national summary record, ie an adverse 
reaction, complication from anaesthesia, critical condition, ongoing treatment, 
implant, change of treatment routine, or infection. Each of these will be 
either an EVALUATION.adverse_reaction_risk, EVALUATION.problem_diagnosis, or 
EVALUATION.precaution. The patient’s GP normally records the information, and 
this code set is supposed to be used to specify where the GP got the 
information about each of the entries from.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Tuesday, January 17, 2017 11:36 AM
To: For openEHR technical discussions 
Subject: Re: Use of RM:provider

Hi Silje,

I would agree with your and Thomas's assessment. This codeset does not really 
fit with provider, or indeed with any other RM attributes, although many but 
not all of these items could be calculated/ derived from existing attributes.

I guess this is part of a national requirement, and is a similar issue to the 
one we faced in Sweden, where the V-TIM standard was largely aligned with 
openEHR but had some extra specific metadata around Contsys-2 that needed to be 
captured.

This was exactly the purpose for the Extension slot that we are adding to new 
archetypes, so that would be my suggestion. Having said that, I do wonder about 
the purpose of this data -where is the value, over and above what is already 
captured by native openEHR RM. This feels like largely a derived set of data 
for reporting purposes

e,g,



1. Result of test/analysis

We know that from the archetype name

2.   Observed by treating physician

Captured potentially by provider

3.   Patient’s own information
Party = Self

4.   Information from next of kin
Party = carer

5.   Obtained from other records

Can use Feed_audit but practically very difficult to manage.

6.   Other

7.   Reported by responsible clinician

Captured by composer

Can you tell us more about the background?



Ian

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

[https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
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 10:14, Thomas Beale 
> wrote:

Hi Silje,

there is no immediate equivalent of these codes, which have indirect 
equivalents, i.e.

  1.  Result = OBSERVATION; provider = lab; limited to certain archetypes; also 
comes under SOAP 'O' Heading
  2.  Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED 
(physician); limited to certain archetypes; also comes under SOAP 'O' Heading
  3.  Patient information = OBSERVATION, with provider = PARTY_SELF, possibly 
limited to specific archetypes ; also comes under SOAP 'S' heading
  4.  Info from next of kin = OBSERVATION, with provider = PARTY_IDENTIFIED 
(next of kin)
  5.  Info from other records = any ENTRY, with FEEDER_AUDIT set appropriately
  6.  ??
  7.  Reported by responsible clinician could be 1, 2, most EVALUATIONs, 
most/all INSTRUCTIONs some or many ACTIONs; provider = PARTY_IDENTIFIED 
(clinician)

I'd say it can be mostly set by using ENTRY.provider. 5 is a different thing - 
it's about provenance of data obtained from elsewhere. Presumably 6 means 'not 
any of 1-5 or 7'.

I'd also say it isn't a very well designed code-set, and I don't know what use 
it would be in real life...

- thomas

On 16/01/2017 13:14, Bakke, Silje Ljosland wrote:
Hi everyone,

I’ve got a problem about where to put non-identifying information about the 
source of information for an ENTRY. The value set we need to store is the code 
set identified by the OID 2.16.578.1.12.4.1.7498 (Source of information), as 
following:


1.   Result of test/analysis

2.   Observed by treating physician

3.   Patient’s own information

4.   Information from next of kin

5.   Obtained from other records

6.   Other

7.   Reported by responsible clinician

Our first hypothesis was that the reference model element “provider” should be 
used for this, but then someone pointed out that the “provider” should be an 
identifiable person or entity, and not just a generalised coded text like this. 
So, where should this information go, if not in RM:provider?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes

Re: Runtime name suggestions?

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

RE: Runtime name suggestions?

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

Re: Runtime name suggestions?

[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

Re: Use of RM:provider

[Ian McNicoll]

Hi Silje,

I would agree with your and Thomas's assessment. This codeset does not
really fit with provider, or indeed with any other RM attributes, although
many but not all of these items could be calculated/ derived from existing
attributes.

I guess this is part of a national requirement, and is a similar issue to
the one we faced in Sweden, where the V-TIM standard was largely aligned
with openEHR but had some extra specific metadata around Contsys-2 that
needed to be captured.

This was exactly the purpose for the Extension slot that we are adding to
new archetypes, so that would be my suggestion. Having said that, I do
wonder about the purpose of this data -where is the value, over and above
what is already captured by native openEHR RM. This feels like largely a
derived set of data for reporting purposes

e,g,

1. Result of test/analysis

We know that from the archetype name

2.   Observed by treating physician

Captured potentially by provider

3.   Patient’s own information
Party = Self

4.   Information from next of kin
Party = carer

5.   Obtained from other records

Can use Feed_audit but practically very difficult to manage.

6.   Other

7.   Reported by responsible clinician

Captured by composer

Can you tell us more about the background?


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 10:14, Thomas Beale  wrote:

> Hi Silje,
>
> there is no immediate equivalent of these codes, which have indirect
> equivalents, i.e.
>
>1. Result = OBSERVATION; provider = lab; limited to certain
>archetypes; also comes under SOAP 'O' Heading
>2. Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED
>(physician); limited to certain archetypes; also comes under SOAP 'O'
>Heading
>3. Patient information = OBSERVATION, with provider = PARTY_SELF,
>possibly limited to specific archetypes ; also comes under SOAP 'S' heading
>4. Info from next of kin = OBSERVATION, with provider =
>PARTY_IDENTIFIED (next of kin)
>5. Info from other records = any ENTRY, with FEEDER_AUDIT set
>appropriately
>6. ??
>7. Reported by responsible clinician could be 1, 2, most EVALUATIONs,
>most/all INSTRUCTIONs some or many ACTIONs; provider = PARTY_IDENTIFIED
>(clinician)
>
> I'd say it can be mostly set by using ENTRY.provider. 5 is a different
> thing - it's about provenance of data obtained from elsewhere. Presumably 6
> means 'not any of 1-5 or 7'.
>
> I'd also say it isn't a very well designed code-set, and I don't know what
> use it would be in real life...
>
> - thomas
>
> On 16/01/2017 13:14, Bakke, Silje Ljosland wrote:
>
> Hi everyone,
>
>
>
> I’ve got a problem about where to put non-identifying information about
> the source of information for an ENTRY. The value set we need to store is
> the code set identified by the OID 2.16.578.1.12.4.1.7498 (Source of
> information), as following:
>
>
>
> 1.   Result of test/analysis
>
> 2.   Observed by treating physician
>
> 3.   Patient’s own information
>
> 4.   Information from next of kin
>
> 5.   Obtained from other records
>
> 6.   Other
>
> 7.   Reported by responsible clinician
>
>
>
> Our first hypothesis was that the reference model element “provider”
> should be used for this, but then someone pointed out that the “provider”
> should be an identifiable person or entity, and not just a generalised
> coded text like this. So, where should this information go, if not in
> RM:provider?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF
>
>
>
> ___
> 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: Use of RM:provider

[Thomas Beale]

Hi Silje,

there is no immediate equivalent of these codes, which have indirect 
equivalents, i.e.


1. Result = OBSERVATION; provider = lab; limited to certain archetypes;
   also comes under SOAP 'O' Heading
2. Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED
   (physician); limited to certain archetypes; also comes under SOAP
   'O' Heading
3. Patient information = OBSERVATION, with provider = PARTY_SELF,
   possibly limited to specific archetypes ; also comes under SOAP 'S'
   heading
4. Info from next of kin = OBSERVATION, with provider =
   PARTY_IDENTIFIED (next of kin)
5. Info from other records = any ENTRY, with FEEDER_AUDIT set appropriately
6. ??
7. Reported by responsible clinician could be 1, 2, most EVALUATIONs,
   most/all INSTRUCTIONs some or many ACTIONs; provider =
   PARTY_IDENTIFIED (clinician)

I'd say it can be mostly set by using ENTRY.provider. 5 is a different 
thing - it's about provenance of data obtained from elsewhere. 
Presumably 6 means 'not any of 1-5 or 7'.


I'd also say it isn't a very well designed code-set, and I don't know 
what use it would be in real life...


- thomas


On 16/01/2017 13:14, Bakke, Silje Ljosland wrote:


Hi everyone,

I’ve got a problem about where to put non-identifying information 
about the source of information for an ENTRY. The value set we need to 
store is the code set identified by the OID 2.16.578.1.12.4.1.7498 
(Source of information), as following:


1.Result of test/analysis

2.Observed by treating physician

3.Patient’s own information

4.Information from next of kin

5.Obtained from other records

6.Other

7.Reported by responsible clinician

Our first hypothesis was that the reference model element “provider” 
should be used for this, but then someone pointed out that the 
“provider” should be an identifiable person or entity, and not just a 
generalised coded text like this. So, where should this information 
go, if not in RM:provider?


Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF



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