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: 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:
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
