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 <[email protected]> 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: > [email protected]] *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: [email protected] > twitter: @ianmcnicoll > > > > Co-Chair, openEHR Foundation [email protected] > > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > > On 18 January 2017 at 15:10, Bakke, Silje Ljosland < > [email protected]> 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 > <https://twitter.com/arketyper_no> > > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
