date:20170118

SV: Context in persistent COMPOSITION archetypes?

2017-01-18 Thread Bjørn Næss

To the first question – technical: Is it possible to have context on a
persistent composition?
Yes – I think that should be possible. Some will argue that the context is an
EVENT_CONTEXT and such context should only be used for event based
Compositions. I think it makes sense to have some context also for the
persistent ones.

Then to Ian’s follow up –what is the underlying use-case here?
The use-case seems to be based on a distributed environment where several
healthcare providers commit their data for a given EHR (subject of care). This
seems to be a asynchronous messaging architecture where they send messages (as
Compositions) to update a central repository.
If this is true – then I agree with Ian that the synchronization of the
underlying data will be hard .

The idea seems to be to keep a clinical concept within one persistent
composition. I guess the intention by this is to be able to update a single
source for the information about a specific concept. Then the central service
must do some bookkeeping to make sure that each concept is updated by creating
a new version of the specific persistent composition.

Another approach would be a more synchronized architecture. Where you first
query for the concepts and get back all the LOCATABLE’s . Then the client will
be able to create new versions of each entry (by creating new versions of the
surrounding container). And when doing this – why would you like to constraint
the model to only have one ENTRY for each COMPOSITION? This question leads me
to suggest that the context you would like to add should be on the ENTRY –
being an EVALUATION, OBSERVATION, etc. Could this be a solution?

BTW: We (DIPS) are implementing openEHR FOLDER to support use-cases like this.
We will use FOLDER to realize a “FOLDER DOCUMENT”. This is kind of a persistent
composition – but since it is a FOLDER it can combine several autonomous
COMPOSITIONS in a shared view. I think this actually is PERSISTENT COMPOSITION
done the right way. I think it would be used for all use-cases where we today
create a PERSISTENT Template to model i.e. Social Summary, Previous Diseases.
We will post some specifications/descriptions on this soon.

/Bjørn

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På
vegne av Ian McNicoll
Sendt: 18. januar 2017 17:22
Til: For openEHR technical discussions
Emne: Re: Context in persistent COMPOSITION archetypes?

Hi Silje,

Can you tell us more about the background? Are you trying to provide the model
for the message, or to store the data when it is received (or both)?

Where does the data come from and how is it managed / curated? Does it come
from a single clinician (presumably GP) or from multiple sources? Is it
curated/managed by the GP or is it managed by the recipient.

In the UK, all of the emergency summaries are essentially copies of summaries
managed and curated by the GP, so there is no need to synchronise lists, as it
appears you are trying to do here. That is pretty difficult and even with
simpler, safer labs messages, my understanding is that people have stopped
sending 'diffs' i.e just a note of updates/changes in favour of re-sending the
current full version of the message again.

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 18 January 2017 at 15:10, Bakke, Silje Ljosland
>
wrote:
Hi,

Is is possible to add context, ie actual text or other data types, to a
persistent composition. The Archetype Editor doesn’t seem to support this. The
use case is entries to the Norwegian national summary records, where each entry
needs to be given a code (of course using a specific, National code set) about
whether this is a new entry, a change to an existing entry, a verification or
an refutation. Our hypothesis is to use a specific persistent COMPOSITION
archetype for these entries, with only one entry per composition, and a coded
text element to hold the code for the type of entry.

Is there a better way of achieving what we need to do here?

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

Re: Context in persistent COMPOSITION archetypes?

2017-01-18 Thread Ian McNicoll

Hi Silje,

Can you tell us more about the background? Are you trying to provide the
model for the message, or to store the data when it is received (or both)?

Where does the data come from and how is it managed / curated? Does it come
from a single clinician (presumably GP) or from multiple sources? Is it
curated/managed by the GP or is it managed by the recipient.

In the UK, all of the emergency summaries are essentially copies of
summaries managed and curated by the GP, so there is no need to synchronise
lists, as it appears you are trying to do here. That is pretty difficult
and even with simpler, safer labs messages, my understanding is that people
have stopped sending 'diffs' i.e just a note of updates/changes in favour
of re-sending the current full version of the message 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 18 January 2017 at 15:10, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi,
>
>
>
> Is is possible to add context, ie actual text or other data types, to a
> persistent composition. The Archetype Editor doesn’t seem to support this.
> The use case is entries to the Norwegian national summary records, where
> each entry needs to be given a code (of course using a specific, National
> code set) about whether this is a new entry, a change to an existing entry,
> a verification or an refutation. Our hypothesis is to use a specific
> persistent COMPOSITION archetype for these entries, with only one entry per
> composition, and a coded text element to hold the code for the type of
> entry.
>
>
>
> Is there a better way of achieving what we need to do here?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF
>
> Tel. +47 40203298 <+47%20402%2003%20298>
>
> 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
>
___
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

2017-01-18 Thread Bakke, Silje Ljosland

Hi Bjørn and Ian!

The original use case for this code set was adverse reactions, but with the 
development of the national summary records, it’s been expanded for use with 
other kinds of critical information as specified below. This means that it 
needs to be used across the adverse reaction risk, problem/diagnosis and 
precaution archetypes, and I think therefore making a new cluster for use in 
the Extension slots is the best way to go forward.

@Ian: Yes, this information is mandatory for each entry. They’re generally few 
and seldom changed, so I don’t think there’s too much overhead from this:
[cid:image001.png@01D271A4.637D58A0]
Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Wednesday, January 18, 2017 12:33 PM
To: For openEHR technical discussions 
Subject: Re: Use of RM:provider

Hi Bjorn,

Thanks - it makes much more sense in the context of Adverse reaction but TBH I 
still doubt very much if this 'provenance' source metadata is captured or known 
reliably. I asked a couple of UK GP colleagues and they agreed. I would argue 
that this data a) often not available b) unreliable c) a pain in the neck to 
manage and d) not something you ever want to do decision support on.

If an allergy has been asserted, it needs to be regarded as positive and kick 
decision support into life, no matter how vague the provenance or potentially 
unreliable the witness.

But hey, that's what the extension slot in the archetype is for :)

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 18 January 2017 at 10:24, Bjørn Næss > 
wrote:
Hi
The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of information) 
) is defined as  “options to specify the source of data for an allergic 
reaction” (my translation).

Which means this is specific for adverse reaction – and I think it should be 
archetyped to model this requirement. If it is only national then there should 
be some extension slots in the Archetypes – or we need some specialization of 
the Archetype to handle this.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 På vegne av Ian McNicoll
Sendt: tirsdag 17. januar 2017 13.43
Til: For openEHR technical discussions 
>
Emne: Re: Use of RM:provider

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

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

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á  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 :
>
>> 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
>
___
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

2017-01-18 Thread Ian McNicoll

Hi Bjorn,

Thanks - it makes much more sense in the context of Adverse reaction but
TBH I still doubt very much if this 'provenance' source metadata is
captured or known reliably. I asked a couple of UK GP colleagues and they
agreed. I would argue that this data a) often not available b) unreliable
c) a pain in the neck to manage and d) not something you ever want to do
decision support on.

If an allergy has been asserted, it needs to be regarded as positive and
kick decision support into life, no matter how vague the provenance or
potentially unreliable the witness.

But hey, that's what the extension slot in the archetype is for :)

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 18 January 2017 at 10:24, Bjørn Næss  wrote:

> Hi
>
> The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of
> information) ) is defined as  “*options to specify the source of data for
> an allergic reaction*” (my translation).
>
>
>
> Which means this is specific for adverse reaction – and I think it should
> be archetyped to model this requirement. If it is only national then there
> should be some extension slots in the Archetypes – or we need some
> specialization of the Archetype to handle this.
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Produktansvarlig
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> *Fra:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *På vegne av* Ian McNicoll
> *Sendt:* tirsdag 17. januar 2017 13.43
> *Til:* For openEHR technical discussions  openehr.org>
> *Emne:* Re: Use of RM:provider
>
>
>
> 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 <07752%20097859>
> office +44 (0)1536 414994 <01536%20414994>
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> [image:
> 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 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

SV: Use of RM:provider

2017-01-18 Thread Bjørn Næss

Hi
The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of information) 
) is defined as  “options to specify the source of data for an allergic 
reaction” (my translation).

Which means this is specific for adverse reaction – and I think it should be 
archetyped to model this requirement. If it is only national then there should 
be some extension slots in the Archetypes – or we need some specialization of 
the Archetype to handle this.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Ian McNicoll
Sendt: tirsdag 17. januar 2017 13.43
Til: For openEHR technical discussions 
Emne: Re: Use of RM:provider

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

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

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

SV: Context in persistent COMPOSITION archetypes?

Re: Context in persistent COMPOSITION archetypes?

RE: Use of RM:provider

Re: Runtime name suggestions?

Re: Use of RM:provider

SV: Use of RM:provider

6 matches

Site Navigation

Mail list logo

Footer information