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
