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 <silje.ljosland.ba...@nasjonalikt.no<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<tel:+47%20402%2003%20298> 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.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
