You've all been very helpful and clear in responding to my questions. What I've learned is that the basic unit of storage--and retrieval--is a single composition, nothing bigger, nothing smaller, and certainly not the complete roster of compositions as I had thought (based on my mistaken notion that one could not serialize, easily, only a section of a complex instantiated object tree). That resolves a lot of my concerns.
However, this has taken the conversation into an interesting area, namely, those types of compositions of that contain what you call "persistent" information, such as drug lists, problem lists, family history and so on, where subsequent compositions must modify the states of earlier compositions and where, as a result, subsequent compositions must embody and repeat much of what is contained in prior compositions. The same issue, I would think, would also arise in your workflow situations (observation / instruction / action), where, again, subsequent compositions--often in hierarchical relation to yet prior compositions--must modify the states of items in prior compositions. Once again, since everything--and its hierarchical context--is immutable and cannot be modified in place, you have to reproduce that entire context in each composition that modifies the state--or has a dependency on--of something, however small, in a prior composition. And to compound the issue even more, these subsequent compositions, whose contents address prior compositions, might also contain "event" as opposed to "persistent" information. So, as states of items in prior compositions undergo state changes, it is not a simple matter of apples-to-apples substitutions as you replace them with new versions, because both prior and subsequent compositions could also contain "event" information. So maybe the versioning process actually splits compositions, declaring only pieces of them obsolete. Obviously, you've all found ways to make this work, perhaps elegantly, but, as some are suggesting, at very least this would enlarge the amount and scope of information involved in a single commit, thus inviting contention. I see some real complexity here. I'll have to read more about how versioning works, using the references you have provided me. I did look at the common_im.pdf Eric referenced, and versioning, from my brief exposure to it in this PDF, is obviously one of the *most* complex aspects of the openEHR specification, as well it would be. An openEHR record, as I'm coming to understand it, is basically an indexed collection of very sophisticated "documents" analogous to PDFs, "documents," which, like ordinary documents, are persisted as single digital streams that can be hashed and signed, and that must also be deserialized and parsed. That seems good for adding stand-alone new information to the collection, but somewhat more complex for new information with a distinct dependence on stuff in prior "documents." This, of course, forbids in-place editing of state; a new document must be issued to change the old and--necessarily--embody the old, even what has not changed, in the process. A completely different approach would entail saving everything in conventional RDBMS tables and columns or object databases, and allow in-place modifications--if one could solve the problem of preserving prior states of entire aggregations of data, signing and attestation, to say nothing of the problem of sparse data schemas. I can see why you've gone the way you have, but in so doing, you have your own set of challenges. But who doesn't? Randy On Mon, Apr 15, 2013 at 10:15 AM, Bert Verhees <bert.verhees at rosa.nl> wrote: > On 04/15/2013 03:37 PM, Grahame Grieve wrote: > > "big risk" - it's a combination of how likely it is, and how bad it is if > they are. > > Generally, current location, current medication lists, summary lists are > things where contention can happen. Quite often, I've seen, a cascade of > things will happen on a patient simultaineously as multiple people focus on > the patient > > The other place where contention is a problem I've experience has been > pathology reports that are not complete - in a busy lab doing 2000 > reports/day, I observed editing contention 10-20x a day on average. That's > pretty low, but the consequences of a clash.... bad..... > > > In the lab, are that updates, or new records? > How do you deal with long time transactions? Suppose a lab edits a > dataset, saves it in an archetype-model which will be used to store more > items. > Then lab employee does the following test and saves it. Should it be saved > in the same data-set, or in a new version? > I don't think you should have long lasting transactions, lasting longer > then one millisecond. > Maybe in a lab, there should be a client/GUI which stores/caches local > until the results are complete. > So it depends on the EHR-system and archetypes. > > And in the current medicationlist, how big is the chance that two edits > are done simultaneously? > And is it also a GUI question, to refresh the screen, once in a while, so > that the chance of a care-professionalist to be looking at the really > current medications increases from 99,99% to 99,999%? > There can always be a late update from a pharmacy, mostly they update the > system at moment of providing medication, but it can always go wrong, > electricity fall out, etc. > Those screen refreshes are also a GUI-thing. > > But, of course, it must be prevented. But I think you will agree that > there is no need of fancy isolation-schemas. > The most basic one will do. And transactions should never take longer then > a minimum of time. Say one millisecond. > > Not everything needs to be resolved by a OpenEHR-kernel. > Some things are really a GUI matter. > > But I am interested in arguments. > > Bert > > > > Grahame > > > > On Mon, Apr 15, 2013 at 11:25 PM, Bert Verhees <bert.verhees at rosa.nl>wrote: > >> On 04/15/2013 02:56 PM, Grahame Grieve wrote: >> >>> well, that's true for some parts of the record - the historical parts. >>> Other parts, summary parts, that's quite untrue. In most enterprise >>> systems, records tend to be rarely updated, or intensively updated, and not >>> much between >>> >> >> >> Can you give an example of parts of records which are at big risk for >> competitive updates? >> >> Thanks >> Bert. >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > > -- > ----- > http://www.healthintersections.com.au / grahame at > healthintersections.com.au/ +61 411 867 065 > > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130415/f78bf88d/attachment.html>
