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: Thomas BealeDate: Mon, Apr 4, 2016 10:31To:
[email protected];Subject: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 this is just a display requirement, is more UI related
and we need to find ways in the backend to provide the data to address
this requirement, independently of if we have or not singleton
versioned_compositions per persistent compo archetype.
I think it is not just a display requirement, at least in some
countries. There are separate care plans for example in the UK for some
patients for relatively unrelated conditions. Whether separate medication
lists really exist at the clinical level is a question (a bad idea for
obvious reasons, same for allergies), but I suspect it could exist at a
practical level in some places, if a GP or other Meds list is imported into
a hospital environment that has its own medications list; in this case, the
two taken together would be seen as the total logical list, but each part
being owned by a different provider. We need more concrete evidence on this,
but I don't see anything to prevent this sort of thing happening.
OT but related:
Now this got me thinking about commits. Until now, I was
thinking of full composition commits, so if you want to add a
medication to a medication list, you need to commit the data in the
current version, plus the new entry for the new medication. But what
about delta commits? If I didn't changed anything on the current
medications, can't I just commit the new medication? Is this possible
or somebody implemented something like this?
openEHR doesn't say how to store the Versions, only that the logical
view needs to be that each Version appears to have the full content. If you
want to engineer a delta-based storage mechanism, you can, the specs don't
prevent that. Note that implementing differential representations for object
structures is non-trivial, but doable (AOM2 does it for example); if you are
storing some serial format, then you can potentially use text-based diffing,
although you have to be careful of ordering within Hashes and Lists, which
tends to break purely logical versioning e.g. on XML.
I would think of that as a commit "mode" that applies for
amendment and modification change_type, and would allow to log
individually added entries, and keep track of whole "singleton"
persistent lists.
Well, all it really means is that a function might be added to the EHR
API that enables you to 'add' just a medication to a medication list, and
the API will actually figure out how to create the whole composition, do any
diffing, and store the proper Composition within a Contribution. Personally
I think a better way that I have advocated for some years is a business
level service + API called 'medication list' that provides functions like:
getAll: List<Entry> getAllIds: List<String>
addMedicationOrder (newMed: Instruction) removeMedicationOrder
(id: String) getMedicationOrdersInState (aState: StateEnum) // e.g.
'active', etc putAction (anAction: Action; orderId: String) etc
that's just one idea of the service. Obviously it can be done
differently. The point is that it would provide all the needed conversions
between a functional/transactional interface, and the appropriate openEHR
structures. It would do all the building of Compositions and so on, and
make the correct calls to the EHR service.
I would foresee the same kind of service for:
allergies & interactions vaccinations procedures list
care plan patient diary doctor's diary etc - thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
