Dear all,
during a recent Ocean design meeting in Adelaide, it became clear that it would be useful if all “top-level” objects in openEHR (defined as per this page: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/html/architecture/overview/Output/design_of_ehr.html#1154670) had their uid attribute set to the value of the VERSION object used to contain them. Details about what this version identifier look like can be found here: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/html/architecture/overview/Output/identification.html or for the real details, here: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf (change control section; see particularly fig 11).
In short, the unique id of one Version in a set of Versions of the one logical object looks like this:
F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC::au.gov.health.rdh::2
Where the leading Guid part is the uid of the containing VersionedObject (i.e. the thing that contains many versions). Currently in openEHR these ids are recorded in the VERSIONED_OBJECT and VERSION instances.
Currently in openEHR, the uid attribute (inherited from LOCATABLE) is not used, since openEHR identification is based on versioning and paths.
The proposal here is simply to write the unique version id into the uid attribute of the data object being versioned (i.e. Composition, etc - any top-level object as per above), not just into the Version object containing it. This would have the following effects:
- any openEHR top-level content object would be uniquely globally identified in a self-standing manner, i.e. not just in the context of a Version object containing it
- thus any such content object could safely be used on its own, and be traceable back to its original repository
- implementers of openEHR that don’t implement the versioning semantics as per the reference model could still produce valid top-level content objects
A counter-argument to the proposal would be that all openEHR top-level objects should always travel as part of a Version object. This has its attractions: the Version object (see http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html) includes the commit audit, the contribution id, and any digital signature - all useful if not essential information items. An alternate stance would be for openEHR to treat the Version object as the lowest level shareable entity - which we already do in EHR Extracts (specification draft forthcoming).
Following the proposal here of course does not mean invalidating the statement above: I am inclined to do both, i.e. always write the Version uid into the content object of the version (Version.data on the diagram) and declare that Versions are the lowest level of transportable entity. The utility of the uid in content objects is then mainly restricted to identifying them inside systems, e.g. during query execution and so on.
thoughts?