Hi Thomas, Again, you've advanced my grasp of openEHR.
>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. Your comment here is in the context of persistent Compositions, and I think what you're saying is that these are a special case: persistent Compositions, unlike event Compositions, contain only *one* kind of persistent information, and no event information, thus allowing clean substitutions when that persistent information is later updated. This would avert the horrible scenario I suggested, involving updating heterogeneous persistent Compositions. If I'm grasping you, this makes perfect sense. >Systems do have to be careful to create references that point to particular versions. Does that mean that tracing a web of connections with current relevance requires systems to present invalidated Compositions to users? Or are the links themselves revised to point to the replacement Compositions? If the latter, how does one avoid having to recommit whole sets revised compositions involved in the affected thread of links? It would seem that you can't just swap out one item in a tangled web, at least without some very sophisticated compensatory activities. Or maybe links are somehow named in such a way as always to point to the latest version of something, which you seemed to suggest is possible (version-proof links?). OpenEHR is a remarkable piece of technology. An EHR record is externally a collection of independent and separate documents called Compositions that can be invalidated and versioned and swapped out at any time. Yet, logically and internally, it is magically a vast graph of nodes and edges and vertices, with connections not just within archetypes but also between archetypes. Logically, the nodes (typically archetypes) are not deleted (usually) nor do they lose their initial identity when their contents change or when links between them are altered. One wonders, then, why not just use a graph DB instead of a collection of documents to house the information? Wouldn't that be a shorter path to the same end and reduce some of the versioning complexity (you'd say that would increase versioning complexity)? Perhaps there are some openEHR implementations that are doing just that. No? Could an openEHR system use a graph DB and still be considered openEHR? Do you have a picture or map, somewhere, of your metadata graph, or must I examine individual achetypes to see all the links between them? >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. What is the motivation for that? To increase the granularity of externally-referenceable objects? What current problem would this solve? >We need something to keep us off the streets... Not a worry for you, sir. I'll embarrass you by letting on here how impressed I've been with the raw intellect everywhere evident in what I take to be chiefly your creation and the literary talent you have exercised in making it all clear. Great work! Randy On Mon, Apr 15, 2013 at 3:39 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > 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 > > > > _______________________________________________ > 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/20130416/e14f1c0b/attachment.html>
