Context in persistent COMPOSITION archetypes?

[Bakke, Silje Ljosland]

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

Re: Context in persistent COMPOSITION archetypes?

[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

SV: Context in persistent COMPOSITION archetypes?

[Bjørn Næss]

Hi

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<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto: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 
mailto: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
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.ope

Re: Context in persistent COMPOSITION archetypes?

[Ian McNicoll]

Sorry,
I didn't reply to the question about context in persistent compositions.
Actually right now this is not possible because there is a rule in the rm
which says that persistent compositions cannot have context. This has been
recognised as unhelpful and there was a change request in to remove that
rule which may now have gone through. I'll check.

In fact it really does not matter too much right now since setting
persistent does not actually do anything technically. I.e. It is still up
to tbe implementer to save the data in the right way.

Actually the suggestion to store each entry in its own separate composition
is very similar to what we are doing in the ripple project, albeit for
slightly different reasons. Essentially we are treating the problem list as
a virtual document which does mean that each entry carries its own
composition context metadata.

Still think synchronisation is scary!

Ian
On Wed, 18 Jan 2017 at 23:18, Bjørn Næss  wrote:

> Hi
>
>
>
> 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
>
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>
> Director, freshEHR Clinical Informatics Ltd.
> Director