RE: Composition commit and change types

2016-04-04 Thread pablo pazos
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 persisten

Re: Composition commit and change types

2016-04-04 Thread Ian McNicoll
Hi Pablo, I think there are lots of interesting approaches (though potentially challenging in complex environments) but I would definitely want to handle the question of 'diffs or not' behind the service layer. As a consumer I just want to be sure that the current composition accurately reflects c

RE: Composition commit and change types

2016-04-04 Thread pablo pazos
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 h

Re: Composition commit and change types

2016-04-04 Thread Thomas Beale
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 hav

Re: Composition commit and change types

2016-04-04 Thread pazospablo
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 message--From:

Re: CAMSS assessment of openEHR

2016-04-04 Thread Thomas Beale
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

2016-04-04 Thread Erik Sundvall
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 threats?” > > · Unabl

Re: CAMSS assessment of openEHR

2016-04-04 Thread Thomas Beale
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 rele

Re: Composition commit and change types

2016-04-04 Thread Thomas Beale
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 this

RE: CAMSS assessment of openEHR

2016-04-04 Thread Bakke, Silje Ljosland
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 consulta