On 15/04/2013 17:11, Randolph Neall wrote: > 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.
actually, versioning is suppprted (and routinely used) for all Compositions. Its meaning for non-persistent Compositions is that it is an error correction or update. The only real difference is that there will be many more version updates to persistent Compositions over the lifetime of an EHR than for any other kind of Composition in that EHR. > 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. the change set in openEHR is actually not a single Composition, it's a set of Composition Versions, which we call a 'Contribution'. Each such Version can be: a logically new Composition (i.e. a Version 1), a changed Composition (version /= 1) or a logical deletion (managed by the Version lifecycle state marker). So a visit to the GP could result in the following Contribution to the EHR system: * a new Composition containing the note from the consultation * a modified Medications persistent Composition * a modified Care Plan persistent Composition. We don't tend to see the relationships between the Compositions and other Compositions outside of the Contribution (i.e. the current commit) as hierarchical containment, rather they are references. So there are LINK objects containing URIs that point to other Compositions. The data type DV_EHR_URI can also be used directly in data to point to other data objects in the same or another EHR. If for some reason some historical Composition had to be updated due to the current commit, it just gets a new Version as part of the Contribution. > 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. due to the referencing approach, this is not really a problem. But systems do have to be careful to create references that point to particular versions, or 'latest version' (whatever it might be). > > 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 have to say, in the systems I know of, the contention issue is vanishingly small. It's not to say it will never occur, but it's not a general problem that I know of. > 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. luckily no clinical person ever sees this in archetype land, or else they would all go mad ;-) (After shooting the evil spec developers for having the temerity to think they should even see such gears and cogs). > > 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. there is an emerging set of 'second order' object definitions, that use the URI-based referencing approach in very sophisticate ways to represent things like care plans, medication histories and so on. I can't point to a spec right now, but they will start to appear. > > 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? > it's true, but the gain from avoiding the 3NF modelling approach is that any data complexity can be accommodated - it doesn't matter if someone comes up with a weird microbiology result structure with 95 nodes of data in some very specific tree structure - the database and query service just keep working. Referencing, larger logical structures like 'episodes', and the update semantics don't come for free, and require careful design. So I think we have bought into a new area of difficulty, as the price of quite a significant gain over 'single level' systems where the class model or ER model encode all the information semantics. We need something to keep us off the streets... - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130415/ec6a01aa/attachment-0001.html>
