RE: Composition commit and change types

Eng. Pablo Pazos Gutiérrez http://cabolabs.com > From: i...@freshehr.com > Date: Mon, 4 Apr 2016 21:12:00 +0100 > Subject: Re: Composition commit and change types > To: openehr-technical@lists.openehr.org > > Hi Pablo, > > I think there are lots of interesting approaches

RE: Composition commit and change types

Pazos Gutiérrez http://cabolabs.com Subject: Re: Composition commit and change types To: openehr-technical@lists.openehr.org From: thomas.be...@openehr.org Date: Mon, 4 Apr 2016 19:50:50 +0100 On 04/04/2016 19:14, pazospa...@hotmail.com wrote:

Re: Composition commit and change types

On 04/04/2016 19:14, pazospa...@hotmail.com wrote: Hi Thomas, What about having the 'delta' mode just at the API level? Storage might not store delta objects, just full objects, but the API allows to send only what was added, modified or deleted instead of the full compo? then you

Re: Composition commit and change types

Hi Thomas, What about having the 'delta' mode just at the API level? Storage might not store delta objects, just full objects, but the API allows to send only what was added, modified or deleted instead of the full compo? Sent from my LG Mobile -- Original

Re: Composition commit and change types

On 04/04/2016 07:23, pablo pazos wrote: 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

RE: Composition commit and change types

es any sense? Thanks! -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com From: heath.fran...@oceaninformatics.com To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org Subject: RE: Composition commit and change types Date: Mon, 4 Apr 2016 05:35:13 + Hi Pablo, I did inc

RE: Composition commit and change types

__ From: heath.fran...@oceaninformatics.com To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org CC: openehr-technical@lists.openehr.org Subject: Re: Composition commit and change types Date: Sun, 3 Apr 2016 23:36:25 + Hi Ian and Pablo, Although I don't like comme

RE: Composition commit and change types

rrez http://cabolabs.com From: heath.fran...@oceaninformatics.com To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org CC: openehr-technical@lists.openehr.org Subject: Re: Composition commit and change types Date: Sun, 3 Apr 2016 23:36:25 + Hi Ian and Pablo, Although I don't like c

Re: Composition commit and change types

ith change_type creation, and version > them using amendment or modification. > > Does this makes sense? If yes, maybe this can help other implementations :) > > -- > Kind regards, > Eng. Pablo Pazos Gutiérrez > http://cabolabs.com > >> From: i...@freshehr.com >> D

Re: Composition commit and change types

s sense? If yes, maybe this can help other implementations :) > > -- > Kind regards, > Eng. Pablo Pazos Gutiérrez > http://cabolabs.com > >> From: i...@freshehr.com >> Date: Sun, 3 Apr 2016 11:06:53 +0100 >> Subject: Re: Composition commit and change types >>

RE: Composition commit and change types

amendment or modification. Does this makes sense? If yes, maybe this can help other implementations :) -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com > From: i...@freshehr.com > Date: Sun, 3 Apr 2016 11:06:53 +0100 > Subject: Re: Composition commit and change types >

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

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

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.

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:

Re: Composition commit and change types

Hi Pablo, When I am advising implementers on this, I use the following categories ... ## Composition Commit Styles Depending on the clinical requirement, 3 styles of commit strategy are suggested. 1. **’Event’** e.g Nursing observations, clinical encounters, reports. Each time the