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