RE: Composition commit and change types

I agree with that, rephrasing, this "delta mode" would be just an API *feature*. Also both modes full and delta can be supported by the same API, with the same results when querying data back. This might not be part of a generic API spec, but more a concrete ITS. I think especially for

RE: Composition commit and change types

I think that can work for some implementations. What I was thinking is not adding parts to an existing compo, but to commit a full COMPO, just with the changes. That means, the newObject would be a COMPOSITION or even a VERSION. If this is for the Problem List, to add a new one, the COMPO will

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: CAMSS assessment of openEHR

I forgot, w.r.t. to versioning of archetypes, this is the specification that applies. On 04/04/2016 15:51, Erik Sundvall wrote: Adding some thoughts below. On Mon, Apr 4, 2016 at 4:02 PM, Thomas Beale

Re: CAMSS assessment of openEHR

Adding some thoughts below. On Mon, Apr 4, 2016 at 4:02 PM, Thomas Beale wrote: > > 4. A.26: “Does the maintenance organisation for the technical > specification or standard have sufficient finances and resources to be sure > of freedom from short- to medium-term

Re: CAMSS assessment of openEHR

On 04/04/2016 14:07, Bakke, Silje Ljosland wrote: Hi, The project has now done a preliminary CAMSS assessment of openEHR. It’s identified some issues that I would like some input on: 1.A.16: “Are the technical specification or standards reviewed using a formal review process with all

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: CAMSS assessment of openEHR

Hi, The project has now done a preliminary CAMSS assessment of openEHR. It’s identified some issues that I would like some input on: 1. A.16: “Are the technical specification or standards reviewed using a formal review process with all relevant external stakeholders (e.g. public

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