RE: Composition commit and change types

I thought you had more specific cases :) Having specific lists per clinician was commented by Karsten on a previous message and I commented on that. I'm not sure at which extent that is a backend issue, an API issue or an UI issue. I would say if this is just a display requirement, is more UI re

RE: Composition commit and change types

Hi Pablo, I did include my scenarios re problem list at the bottom of the email. Having said that there had been some movement around what compositions are persistent due to no context issues so problem list may no longer be a persistent composition. There are similar scenarios for other persist

RE: Composition commit and change types

Hi Heath, > There are way too many use cases where our service is used and many will > break this scenario like merges, distributed EHRs and cross organisational > shared records. It would be helpful if you share which scenarios break the rule I stated on the previous email to improve it. IMHO

Re: Composition commit and change types

Hi Ian and Pablo, Although I don't like commenting on how others implement their systems I would hate for this discussion to become the defacto standard on how the API works in the context of persistent compositions. Although I understand Ian's position on best clinical practice of a single medi

Re: Composition commit and change types

That looks correct to me :) 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.

RE: Composition commit and change types

@Bert, no worries :) @Ian, for now, I'll add a rule like this: If committed compo is persistent If there is no versioned_compo for the root archetype of the committed compo // this check is newIf change_type == creation // only allows to create one persistent compo, all other commits should

Re: Adressing of i.e. discharge summaries

so are we really talking about 'ADT' patterns? On 16/03/2016 07:51, Heath Frankel wrote: Hi Bjorn, Yes we have used these archetypes for representing the service request at both the instruction and composition level. Our instruction starts in a care plan so we have to represent the referred

Re: Usage of Compositoin.Category

these examples from Ian illustrate exactly why we never figured this out before - because of the possible mixture of original content, referenced content, and sometimes copied content e.g. in a discharge summary. The problem is that 'derived' content can occur at a lower granularity than Comp

Re: SV: SV: Usage of Compositoin.Category

On 16/03/2016 05:19, Bjørn Næss wrote: The problem is not to filter in data. The most important feature to support is to filter out data. The proposed solution is to add a new category code to add a new group of Compositions which by default is sorted out. This could be done by archetypes. Bu

Re: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

Hi Daniel, I read most of your thesis, it is fascinating (it's one of those things that requires contemplation, so I have not read it straight through). I recommend others to have a look . One thing that I

Re: Composition commit and change types

" I would focus on intra hospital longitudinal lists since it is very difficult to reach agreement in the enterprise." I agree. These decisions are partly technical but largely down to the level of commitment/ consensus you can get in your clinical community to jointly curate these lists over time

Re: Composition commit and change types

Good info and the criteria makes sense. I would use episodic for things like hospitalization and treatments that are not a knee time thing (event), maybe with help of folders. Also I would focus on intra hospital longitudinal lists since it is very difficult to reach agreement in the e

Re: Composition commit and change types

"All is already versioned, my question is about how to commit compos and if it makes sense to have two different versioned compositions for the same persistent compo archetype" For a persistent composition you should generally only maintain a single instance that is continually updated i.,e same i

Re: Composition commit and change types

Hi Pablo, I disagree for safety reasons. Knowing all of the medications that the patient is taking/should be taking is a critical part of prescribing. Of course it is legitimate to apply filters but I would be very unhappy with an institution that wanted to maintain multiple medication lists. Ian

Re: Composition commit and change types

All is already versioned, my question is about how to commit compos and if it makes sense to have two different versioned compositions for the same persistent compo archetype. Sent from my LG Mobile -- Original message--From: Bert VerheesDate: Sat, Apr 2, 2016 15:01To:

Re: Composition commit and change types

I think that has more to do with the user interface than how compositions are committed, since I can filter meds by who prescribe them with ease. Sent from my LG Mobile -- Original message--From: Karsten HilbertDate: Sat, Apr 2, 2016 04:25To: openehr-technical@lists.openehr.or