Archetyped Package

LOCATABLE descendants may have a uid, containing a GUID. In the current openEHR architecture, GUIDs are not needed to identify data nodes, since paths are used to reference all nodes inside top-level structures (i.e. COMPOSITIONs etc). Accordingly all references between parts of an EHR are represented in terms of LOCATABLE_REFs or DV_EHR_URIs (the former is a reference to an OBJECT_VERSION_ID with a path appended; the latter is the stringified URI form). This would allow for example, one Entry to reference the serum sodium value in another Entry in version 2 of a Versioned Composition for a laboratory test on 12/Apr/2004. The uid attribute will usually be empty in most EHR data in most openEHR EHR systems.

The exception is the top-level types such as COMPOSITION, EHR_STATUS, PARTY etc for which it is recommended to set the uid value to a copy of the uid.object_id() value of the owning VERSION object (usually an ORIGINAL_VERSION), i.e. the leading Uid, which is normally a Guid. This enables easy identification of standalone top-level objects in a serialised form. For example, if the ORIGINAL_VERSION.uid is 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2, the Guid 87284370-2D4B-4e3d-A3F3-F303D2F4F34B would be copied to the contained COMPOSITION.uid field.

Another use for LOCATABLE.uid is in EHR Extracts, which contain serialised expressions of EHR content. In an Extract, uid could be set on some or all nodes to a value generated by concatenating the uid value of the enclosing Version object (i.e. VERSION.uid) and the unique runtime path to the particular node. This may be useful to the receiver system for the purpose of referencing particular data nodes when communicating to the sender, or another system. This use of uid is not however mandatory, since for each node in an Extract item, the uid value can be generated at any time (including at the receiver system).

The model of Feeder audit is designed to satisfy the following requirements with respect to EHR content sourced from non-openEHR systems:

The design of the Feeder audit part of the reference model is based on a generalised model of data communication in which various elements are identified, as follows:

Abstract Model of Feeder Chain illustrates these elements, shown as a "feeder chain", along with typical meta-data available in messages from each system. In general, not much can be assumed about systems in the feeder chain. The originating system may or may not correspond to the place of the clinical activity - it is not uncommon for a pathology company to have a centralised report issuing location while having numerous physical laboratories. There is often limited consistency in the way identifiers are assigned, timestamps are created, and information is structured and coded. In general, information from a feeder system is in response to a request, often a pathology order, although the request/response pattern probably cannot be assumed in all cases.

The idea underlying the openEHR Feeder audit model is that there are two groups of meta-data which should be recorded about an imported information item. The first is medico-legal meta-data about its creation: the system of origin, who created it and when it was created. The second is identifying meta-data for the item from the originating and feeder system, and potentially other intermediate systems in the feeder chain, where necessary to support duplicate detection, version detection and so on.

The potentially available medico-legal meta-data about the received item is as follows:

The above information is equivalent to the audit trail and versioning data captured when information created in an openEHR system is committed in a Composition version.

Various kinds of identifying information may be required including the following:

Some or all of this information will usually be sufficient to perform a number of tasks as follows.

The first task is to support medico-legal investigation into the path of the information item through the health computing infrastructure. This requires the availability of sufficient identifier information that the origin of the information item can be traced. Subject identifiers where available should be used to ensure that the received data go into the correct EHR, by ensuring that the relevant lookups in client directories or other lookup mechanisms can be effected. Again, in rare cases, the subject of the incoming data item may not necessarily be the subject of the EHR - a test result may be made from a relative or other associate which will be stored in the patient’s EHR.

The second is to detect new versions of an item (e.g. interim and final versions of a microbiology test result). This can usually be achieved by using various identifiers as well as the originating system version id and/or content status (interim, final etc). A new openEHR Composition version should always be created for each received version, even where the content does not change at all (e.g. a microbiology test where the result is "no growth" in both interim and final results).

Another task is to disambiguate duplicates (often caused by failure of a network connection during sending) coming from the feeder system. In some cases however duplicates are erroneously given new ids by the feeder system, giving the receiver the impression of a new information. In such cases, a further item of meta-data may be required:

A further problem is that the originating system may send new versions of an item which are not complete in and of themselves, i.e. which only include new or changed elements with respect to a previous send of the same item. An example is a system which sends a correction to an HL7v2 blood test message, where the correction includes just the "serum sodium" data item. In this case, special processing will be required in the openEHR converter component, in order to regenerate a full data item from difference data when it is received. Such processing may also have to take account of deleted items.

In summary, the Feeder audit class design tries to accommodate the recording of as much of the above meta-data as is relevant in any particular case. It is up to the design of openEHR conversion front-end components as well as proper analysis of the situation to determine which identifiers are germane to the needs of traceability. In general, any meta-data of medico-legal significance should be captured where it is available.

Although the design of the openEHR converter is outside the scope of the current document, it is worth considering a common design approach, and where the FEEDER_AUDIT class fits in. An effective way of converting non-openEHR data such as HL7v2 messages, relational data etc, is in two steps. The first is to perform a 'syntactic' conversion to Compositions containing instances of the GENERIC_ENTRY class (described in the Integration IM), using 'legacy archetypes'. The resulting database will contain versioned Compositions containing GENERIC_ENTRY instances; logically this database does not contain EHRs but simply external data converted to openEHR computational form. The relevant FEEDER_AUDIT instances should be attached to the Compositions containing the corresponding GENERIC_ENTRY instances. The second step is to perform a 'semantic' conversion to subtypes of ENTRY, i.e. OBSERVATION, EVALUATION, INSTRUCTION and ACTION, according to standardised clinical archetypes. There are various possibilities for what to do with the Feeder audit. The minimum Feeder audit required on the final instance contains the originating system audit information, but none of the information to do with feeder or intermediate systems. This will satisfy medico-legal needs. Alternatively, a complete copy could be made, even though the feeder-related meta-data is probably only of use in the conversion environment. What the Feeder audit looks like in the EHR proper may depend on local legislation, norms or other factors. Alternative conversion approaches are also possible, in which no intermediate form of data exists.

There is no guarantee that the granularity of information recorded in the feeder system obeys the rules of Entries, Compositions, etc. As a consquence, feeder information might correspond to any level of information defined in the openEHR models. In order to be able to record feeder audit information correctly, the model has to be able to associate an audit trail with any granularity of object. For this reason, feeder audit information is attached to the LOCATABLE class via the feeder_audit attribute, even though it is preferable by design to have it attached to the equivalent of Compositions or at least the equivalent of archetype entities (i.e. Compositions, Section trees and Entries). Its usual usage is to attach it to the outermost object to which it applies. In other words, in most cases, during a legacy data conversion process, the entirety of a Composition needs only one FEEDER_AUDIT to document its origins. In exceptional cases, where feeder data comes in in near real time, e.g. from an ICU database, separate FEEDER_AUDIT objects may need to be generated for parts of a Composition; each commit in this situation will create a stack of versions of one Composition, with a growing number of FEEDER_AUDIT objects attached to internal data nodes, each documenting the last import of data.

The Feeder audit information is included as part of the data of the Composition, rather than part of the audit trail of version committal, because it remains relevant throughout the versioning of a logical Composition, i.e. when a new version is created, the feeder information is retained as part of the current version to be seen and possibly modified, just as for the rest of its content. If the main part of the content is modified so drastically as to make the feeder audit irrelevant, it too can be removed. A second consequence of feeder and legacy systems is that structural data items may need to be synthesised in order to create valid structures, even though the source system does not have them. For example, a system may have the equivalent data of Clusters and Elements (see openEHR Data Structures IM or ISO 13606), but no Entries, Sections or other higher-level data items; these have to be synthesised during conversion. To indicate synthesis of a data node, a FEEDER_AUDIT instance is attached to the LOCATABLE in question, and its change_type set to "synthesised".

The features of the model described so far allow accurate referencing of content as it is known in source systems and intermediate feeder systems. A further feature of the FEEDER_AUDIT class, the original_content attribute allows the original content item itself to be either included inline or pointed to. If a link is used, the usual situation is that the content is in a store associated with the receiving system, such as a message or document database. The content could also be included inline. Since the original_content link is on a FEEDER_AUDIT object, more than one can be used within the same generated Composition if required. It may be deemed preferable to attach only a single link at the top node, i.e. the Composition node, since this establishes basic equivalent between the whole Composition and the whole document or message.