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 persistent compos, the delta mode is smarted than the full revision, and with a little thought/design, might be as safer as the full revision. I'll put this idea in my icebox, since my user base is growing, in the near future I can send a survey to them to see if this might make their life easier. I won't write a line of code for this until I have a change request, and I'm sure this doesn't complicate other features. Either way, it would be useful to have input from commercial implementers about if they support something like this, and also about the original issue -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com
> From: [email protected] > Date: Mon, 4 Apr 2016 21:12:00 +0100 > Subject: Re: Composition commit and change types > To: [email protected] > > 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 changes made. Full revision is a bit dumb but it > is safe! > > Ian > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: [email protected] > twitter: @ianmcnicoll > > Co-Chair, openEHR Foundation [email protected] > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > On 4 April 2016 at 20:18, pablo pazos <[email protected]> wrote: > > 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 have just one EVALUATION with the new problem. If commit > > mode is "delta", the backend will do what it needs to reflect that addition > > to the current Problem List. If the commit mode is "full", that means one > > problem was added and the rest removed. > > > > IMO this can use the same commit(VERSION[] versions, AUDIT_DETAILS audit) > > adding a String mode param or adding another operation > > commit_delta(VERSION[] versions, AUDIT_DETAILS audit). > > > > For my implementation all commits are for completed COMPOS, the API you > > described might allow partial updates to already committed COMPOS, and I > > don't think delta commit should imply partial updates. Delta is just to > > commit a completed COMPO but without the need of replicating all the > > information that hasn't changed. The backend can create the full compo > > internally, that would not be an issue. > > > > Also, that is related with the initial issue: detecting individual changes > > to persistent COMPOS. Sending just the changes, allows to identify those > > with the user responsible for the changes, so it is easier to create lists > > of problems, medications, etc. per user or organization, even if internally > > that is stored in one singleton VERSIONED_COMPO. per persistent archetype. > > > > Consider this is only for my implementation, I'm not looking for defining > > this for the official openEHR API, but can help as input. I want to double > > check my criteria with other implementers before implementing anything :) > > > > -- > > Kind regards, > > Eng. Pablo Pazos Gutiérrez > > http://cabolabs.com > > > > ________________________________ > > Subject: Re: Composition commit and change types > > To: [email protected] > > From: [email protected] > > Date: Mon, 4 Apr 2016 19:50:50 +0100 > > > > > > > > > > On 04/04/2016 19:14, [email protected] 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 have a transactional concept, i.e. 'add', 'remove', 'modify' etc... > > so for me the better way to think about it isn't in terms of data structures > > but in terms of logical changes to the existing state of some Composition. > > > > But the logical thing is just a function of the form > > > > add (atPath: String; newObject: Locatable) > > > > so then it's just a case of what level of domain semantics you want. For > > example, you could have a function: > > > > addEntryToComposition (atPath: String; newEntry: Entry) > > > > so it's not far to get to: > > > > addMedicationOrder (newMed: Instruction) > > > > Now - we don't need a path, since the API knows we are dealing with a > > MedicationList Composition (that should follow an archetype of that name) > > and new medication orders (Instructions) only go in a certain place. > > > > So you can take your pick - the great thing about APIs is you can have as > > many as you like - as long as they all obey the same rules of data > > structuring and validity. > > > > If it makes sense in your environment to create an API of the flavour of the > > first one above I say go for it. > > > > - thomas > > > > > > _______________________________________________ openEHR-technical mailing > > list [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > > openEHR-technical mailing list > > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
