On Wed, Apr 17, 2013 at 1:16 AM, Randolph Neall <randy.neall at veriquant.com>wrote:
> >Using path-based blobbing probably isn't a million miles from such DBs. > Personally I used a wonderful object database called Matisse (still around > today), which essentially operates as a graph db with write-once semantics, > and I would love to have a side-project to build an openEHR system on that. > > I'll talk to you off line sometime about that. I can tell you from my own > experience that it might not be as forbidding as one would think. The more > I've examined the archetypes and seen how they are linked and the linkage > rules are defined, the more excited I've become. There's definitely a way > to do this. > > >Nevertheless, there are a couple of container levels that have > significance in models like openEHR, 13606, CDA and so on: the Composition > (can be seen as a Document) and the Entry (the clinical statement level). > So it's not completely mad to do blobbing at these levels, or build in > other assumptions around them. > > I agree it's not "completely mad" to use your approach partly because you > really do need the information in chunks that smell and feel like > parchments. But what if you could have it both ways? > Hint: think about how you're going to get data out before thinking how you're supposed to keep it. There are lots of possibilities, but you need to anchor those with a single method of access. I suggest a brief look at Archetype Query Language (AQL) > >ah - don't blame me for it. I added some engineering understanding and > integration along the way, but this work started with a bunch of very smart > clinical people who gathered the best set of requirements for the 'EHR' > concept, during the Good European Health Record project. One of them, Dr > Dipak Kalra (now head of department of CHIME at UCL), wrote his PhD > thesis<http://eprints.ucl.ac.uk/1584/> on > EHR requirements, and one outcome of that was the ISO 18308 standard, on > the same topic. Sam Heard and other physicians were key in developing these > requirements and the understanding they have given to the domain have > greatly affected the quality of the development. This plus numerous > technical people, debates, conferences etc have led to the > specifications<http://www.openehr.org/programs/specification/releases/currentbaseline> > you > see today. Have a look at the revision histories, particularly on the EHR > IM and Data types - you'll see a lot of names. > > Of course you'd say that. I've looked at the names. And using a bit of > networking logic, it's not hard to deduce who has been at the center of it > all--and doing much of the writing. But yes, there were also others, and > you know better than I how it all actually balances out. > > Thanks for the considerable time you've spent answering my questions. > > Randy > > > On Tue, Apr 16, 2013 at 4:46 PM, Thomas Beale < > thomas.beale at oceaninformatics.com> wrote: > >> On 16/04/2013 18:55, Randolph Neall wrote: >> >> 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. >> >> >> to be 100% clear: the change set versioning model works for all >> Composition types - a single change set (what we call a Contribution) can >> contain versions of persistent and even Compositions. >> >> Semantically, your understanding above is correct: persistent >> Compositions are always dedicated to a single kind of information, usually >> some kind of 'managed list' like 'current medications', 'vaccinations' etc. >> >> >> >> >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? >> >> >> Normally when a Composition is committed (within a Contribution) and it >> contains a LINK or DV_EHR_URI, that link points to the logical 'latest >> available' target. So the link is always valid. Such a link might point to >> e.g. a lab result Event Composition. The assumption is that the only >> changes to a lab result are corrections or in the case of microbiology and >> some other long period tests, updates - but essentially the latest >> available version = the result. >> >> On the other hand, a link to a care plan might easily point to the care >> plan (usually a persistent Composition) as it was at the moment of >> committal. If the referencing Composition were retrieved, and that link >> dereferenced, an older version of the care plan will be retrieved. >> >> >> 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? >> >> >> absolutely. Using path-based blobbing probably isn't a million miles from >> such DBs. Personally I used a wonderful object database called Matisse >> (still around today), which essentially operates as a graph db with >> write-once semantics, and I would love to have a side-project to build an >> openEHR system on that. >> >> Nevertheless, there are a couple of container levels that have >> significance in models like openEHR, 13606, CDA and so on: the Composition >> (can be seen as a Document) and the Entry (the clinical statement level). >> So it's not completely mad to do blobbing at these levels, or build in >> other assumptions around them. >> >> >> >> 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? >> >> >> for example: provide a fast retrieval 'map' of all medications, including >> all actions, for some care plan, e.g. chemotherapy. >> >> >> >> >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! >> >> >> >> ah - don't blame me for it. I added some engineering understanding and >> integration along the way, but this work started with a bunch of very smart >> clinical people who gathered the best set of requirements for the 'EHR' >> concept, during the Good European Health Record project. One of them, Dr >> Dipak Kalra (now head of department of CHIME at UCL), wrote his PhD >> thesis <http://eprints.ucl.ac.uk/1584/> on EHR requirements, and one >> outcome of that was the ISO 18308 standard, on the same topic. Sam Heard >> and other physicians were key in developing these requirements and the >> understanding they have given to the domain have greatly affected the >> quality of the development. This plus numerous technical people, debates, >> conferences etc have led to the >> specifications<http://www.openehr.org/programs/specification/releases/currentbaseline>you >> see today. Have a look at the revision histories, particularly on the >> EHR IM and Data types - you'll see a lot of names. >> >> - thomas >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://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/20130417/989512a8/attachment-0001.html>
