Archetyped Package

Overview

The archetyped package defines the core types PATHABLE, LOCATABLE, ARCHETYPED, and LINK. It is illustrated in common.archetyped Package.

RM common.archetyped
Figure 1. common.archetyped Package

The PATHABLE Class

The PATHABLE class defines the pathing capabilities used by nearly all classes in the openEHR reference model, mostly via inheritance of LOCATABLE. The defining characteristics of PATHABLE objects are that they can locate child objects using paths, and they know their parent object in a compositional hierarchy. The parent feature is defined as abstract in the model, and may be implemented in any way convenient.

A number of functions provide the path functionality, of which item_at_path() and items_at_path() are the key functions. The former returns an item corresponding to a unique path, i.e. a path that resolves against the data structure to a single node. The latter returns a list of items corresponding to a non-unique path. These functions can be used safely using the following pattern, but can also be used without checking the validity of paths, if this is known a priori in the code anyway.

if (path_exists (a_path)) {
    if (path_unique (a_path)) {
        x = item_at_path (a_path);
		// process one item
	}
    else {
        list_of_x = items_at_path (a_path);
        //iterate the list
    }
}

The LOCATABLE Class

Most classes in the openEHR reference model inherit from the LOCATABLE class, which defines the idea of 'locatability in an archetyped structure'. LOCATABLE defines a runtime name and an archetype_node_id. The archetype_node_id is the standardised semantic code for a node and comes from the corresponding node in the archetype used to create the data. The only exception is at archetype root points in data, where archetype_node_id carries the archetype identifier in string form rather than an interior node id from an archetype. LOCATABLE also provides the attribute archetype_details, which is non-Void for archetype root points in data, and carries meta-data relevant to root points. The name attribute carries a name created at runtime. The 'meaning' of any node is derived formally from the archetype by obtaining the text value for the archetype_node_id code from the archetype ontology section, in the language required.

The name and archetype_node_id valuesin a LOCATABLE instance are often the same semantically, but may differ. For example, in "problem/SOAP" Sections (i.e. headings), the name of a section at the problem level might be "diabetes", but its meaning might be "problem". The default value for name should be assumed to be the text value in the local language for the archetype_node_id code on the node in question, unless explicitly set otherwise.

Unique Node Identification

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).

some classes in the openEHR architecture that do not inherit from LOCATABLE but require a UID, such as VERSIONED_OBJECT, VERSION etc, explicitly define their own uid attributes.

Feeder System Audit

The data in any part of the EHR may be obtained from a feeder system, i.e. a source system which does not obey the versioning, auditing and content semantics of openEHR (data in the EHR which have been sourced from another openEHR system are dealt with in the Common IM, Change control section). The FEEDER_AUDIT class defines the semantics of an audit trail which is constructed to describe the origin of data that have been transformed into openEHR form and committed to the system. There are a number of aspects to the problem of transforming data for committal into an openEHR system, dealt with in the following subsections.

Requirements

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

  • record medico-legal audit information from the originating system (e.g. pathology lab system) similar to that captured in the AUDIT_DETAILS class in the change_control package;

  • record information identifying the immediate system from which the content was obtained (might not be the originating system);

  • record sufficient information to distinguish incoming items from each other, and to enable the detection of duplicates and new versions of the same item;

  • allow the inclusion of the source content either as a link or inline.

Design Principles

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:

  • the originating system: the computer system where the information item was initially created, e.g. the system at a pathology laboratory or a reporting system for a number of laboratories;

  • intermediate systems: any system which moves information from the originating system to an openEHR system;

  • the feeder system: the intermediate system from which the information item was directly obtained by the openEHR system; this might be the originating system, or it may be a distinct intermediate system;

  • the committing openEHR system: the openEHR system where the information item is transformed into openEHR form and committed as a Composition;

  • openEHR converter: a component whose job it is to convert non-openEHR information into a form compliant with the openEHR reference model and chosen archetypes;

  • original content store: some EHR systems may have an associated persistent repository of content as received from external systems, e.g. a message or document database.

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.

feeder chain
Figure 2. Abstract Model of Feeder Chain

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.

Meta-data

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

  • identifier of the originating system (where the item was originally committed);

  • identifier of the information item in the originating system;

  • agent who committed the item;

  • timestamp of committal or creation of the item;

  • type of change, e.g. initial creation, correction (including deletion of a subpart), logical deletion (e.g. due to cancellation of order);

  • status of information, e.g. interim, final;

  • version id, where versioning is supported.

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:

  • subject identifier (often more than one, e.g. national patient id, GP’s local patient id, lab’s local patient id) are usually recorded and may be required for traceability purposes;

  • subject identifier(s) may identify someone other than the subject of the record as being the subject of the incoming item;

  • location of the feeder system;

  • identifier of the feeder system (which may be one of many at the feeder system location);

  • identifer the feeder system uses for the item in question (often known as an "accession id");

  • identifier of request or order to which the information is a response (sometimes known as a "placer’s request id");

  • identifier of the information item used by the originating system (sometimes known as a "filler’s request id");

  • timestamp(s) assigned by feeder system to the item.

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

Traceability

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.

Version Detection

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).

Duplicate Detection

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:

  • hash or content signature generated (most likely by the converter) from the received information.

Differentially Coded Data

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.

Using Feeder Audit in Converted Data

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.

Structural Correspondence

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".

Original Content

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.

Class Definitions

PATHABLE Class

  • Definition

  • Effective

  • BMM

  • UML

Class

PATHABLE (abstract)

Description

The PATHABLE class defines the pathing capabilities used by nearly all classes in the openEHR reference model, mostly via inheritance of LOCATABLE. The defining characteristics of PATHABLE objects are that they can locate child objects using paths, and they know their parent object in a compositional hierarchy. The parent feature is defined as abstract in the model, and may be implemented in any way convenient.

Inherit

Any

Functions

Signature

Meaning

1..1

parent (): PATHABLE

Parent of this node in a compositional hierarchy.

1..1

item_at_path (
a_path: String[1]
): Any

Pre: path_unique (a_path)

The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item.

0..1

items_at_path (
a_path: String[1]
): List<Any>

List of items corresponding to a non-unique path.

1..1

path_exists (
a_path: String[1]
): Boolean

Pre: not a_path.is_empty

True if the path exists in the data with respect to the current item.

1..1

path_unique (
a_path: String[1]
): Boolean

Pre: path_exists (a_path)

True if the path corresponds to a single item in the data.

1..1

path_of_item (
a_loc: PATHABLE[1]
): String

The path to an item relative to the root of this archetyped structure.
PATHABLE (abstract)

The PATHABLE class defines the pathing capabilities used by nearly all classes in the openEHR reference model, mostly via inheritance of LOCATABLE. The defining characteristics of PATHABLE objects are that they can locate child objects using paths, and they know their parent object in a compositional hierarchy. The parent feature is defined as abstract in the model, and may be implemented in any way convenient.

Inherits: Any

Functions

(abstract) Any.is_equal (
other: Any[1]
): Boolean [1..1]

Value equality: return True if this and other are attached to objects considered to be equal in value.

Parameters
other

Other object for comparison.

Any.equal alias "=", "==" (
other: Any[1]
): Boolean [1..1]

Reference equality for reference types, value equality for value types.

Parameters
other

Other object for comparison.

Any.instance_of (
a_type: String[1]
): Any [1..1]

Create new instance of a type.

Any.type_of (
an_object: Any[1]
): String [1..1]

Type name of an object as a string. May include generic parameters, as in "Interval<Time>".

Any.not_equal alias "!=", "≠" (
other: Ordered[1]
): Boolean [1..1]

True if current object not equal to other. Returns not equal().

parent (): PATHABLE [1..1]

Parent of this node in a compositional hierarchy.

item_at_path (
a_path: String[1]
): Any

Pre: path_unique (a_path) [1..1]

The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item.

items_at_path (
a_path: String[1]
): List<Any> [0..1]

List of items corresponding to a non-unique path.

path_exists (
a_path: String[1]
): Boolean

Pre: not a_path.is_empty [1..1]

True if the path exists in the data with respect to the current item.

path_unique (
a_path: String[1]
): Boolean

Pre: path_exists (a_path) [1..1]

True if the path corresponds to a single item in the data.

path_of_item (
a_loc: PATHABLE[1]
): String [1..1]

The path to an item relative to the root of this archetyped structure.

 
{
    "name": "PATHABLE",
    "documentation": "The `PATHABLE` class defines the pathing capabilities used by nearly all classes in the openEHR reference model, mostly via inheritance of `LOCATABLE`. The defining characteristics of `PATHABLE` objects are that they can locate child objects using paths, and they know their parent object in a compositional hierarchy. The parent feature is defined as abstract in the model, and may be implemented in any way convenient.",
    "is_abstract": true,
    "ancestors": [
        "Any"
    ],
    "functions": {
        "parent": {
            "name": "parent",
            "documentation": "Parent of this node in a compositional hierarchy. \n",
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "PATHABLE"
            }
        },
        "item_at_path": {
            "name": "item_at_path",
            "documentation": "The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item. ",
            "parameters": {
                "a_path": {
                    "_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
                    "name": "a_path",
                    "type": "String"
                }
            },
            "pre_conditions": {
                "Pre": "path_unique (a_path)"
            },
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "Any"
            }
        },
        "items_at_path": {
            "name": "items_at_path",
            "documentation": "List of items corresponding to a non-unique path.",
            "parameters": {
                "a_path": {
                    "_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
                    "name": "a_path",
                    "type": "String"
                }
            },
            "result": {
                "_type": "P_BMM_CONTAINER_TYPE",
                "container_type": "List",
                "type": "Any"
            },
            "is_nullable": true
        },
        "path_exists": {
            "name": "path_exists",
            "documentation": "True if the path exists in the data with respect to the current item. ",
            "parameters": {
                "a_path": {
                    "_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
                    "name": "a_path",
                    "type": "String"
                }
            },
            "pre_conditions": {
                "Pre": "not a_path.is_empty"
            },
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "Boolean"
            }
        },
        "path_unique": {
            "name": "path_unique",
            "documentation": "True if the path corresponds to a single item in the data. ",
            "parameters": {
                "a_path": {
                    "_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
                    "name": "a_path",
                    "type": "String"
                }
            },
            "pre_conditions": {
                "Pre": "path_exists (a_path)"
            },
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "Boolean"
            }
        },
        "path_of_item": {
            "name": "path_of_item",
            "documentation": "The path to an item relative to the root of this archetyped structure.",
            "parameters": {
                "a_loc": {
                    "_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
                    "name": "a_loc",
                    "type": "PATHABLE"
                }
            },
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "String"
            }
        }
    }
}
PATHABLE

LOCATABLE Class

  • Definition

  • Effective

  • BMM

  • UML

Class

LOCATABLE (abstract)

Description

Root class of all information model classes that can be archetyped. Most classes in the openEHR reference model inherit from the LOCATABLE class, which defines the idea of locatability in an archetyped structure. LOCATABLE defines a runtime name and an archetype_node_id.

Inherit

PATHABLE

Attributes

Signature

Meaning

1..1

name: DV_TEXT

Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users.

1..1

archetype_node_id: String

Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. at0005. This value enables a 'standardised' name for this node to be generated, by referring to the generating archetype local terminology.

At an archetype root point, the value of this attribute is always the stringified form of the archetype_id found in the archetype_details object.

0..1

uid: UID_BASED_ID

Optional globally unique object identifier for root points of archetyped structures.

0..1

links: List<LINK>

Links to other archetyped structures (data whose root object inherits from ARCHETYPED, such as ENTRY, SECTION and so on). Links may be to structures in other compositions.

0..1

archetype_details: ARCHETYPED

Details of archetyping used on this node.

0..1

feeder_audit: FEEDER_AUDIT

Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node.

Functions

Signature

Meaning

1..1

concept (): DV_TEXT

Clinical concept of the archetype as a whole (= derived from the archetype_node_id' of the root node)

1..1

is_archetype_root (): Boolean

True if this node is the root of an archetyped structure.

Invariants

Links_valid: links /= Void implies not links.is_empty

Archetyped_valid: is_archetype_root xor archetype_details = Void

Archetype_node_id_valid: not archetype_node_id.is_empty
LOCATABLE (abstract)

Root class of all information model classes that can be archetyped. Most classes in the openEHR reference model inherit from the LOCATABLE class, which defines the idea of locatability in an archetyped structure. LOCATABLE defines a runtime name and an archetype_node_id.

Inherits: Any, PATHABLE

Attributes

name: DV_TEXT [1..1]

Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users.

archetype_node_id: String [1..1]

Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. at0005. This value enables a 'standardised' name for this node to be generated, by referring to the generating archetype local terminology.

At an archetype root point, the value of this attribute is always the stringified form of the archetype_id found in the archetype_details object.

uid: UID_BASED_ID [0..1]

Optional globally unique object identifier for root points of archetyped structures.

links: List<LINK> [0..1]

Links to other archetyped structures (data whose root object inherits from ARCHETYPED, such as ENTRY, SECTION and so on). Links may be to structures in other compositions.

archetype_details: ARCHETYPED [0..1]

Details of archetyping used on this node.

feeder_audit: FEEDER_AUDIT [0..1]

Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node.

Functions

(abstract) Any.is_equal (
other: Any[1]
): Boolean [1..1]

Value equality: return True if this and other are attached to objects considered to be equal in value.

Parameters
other

Other object for comparison.

Any.equal alias "=", "==" (
other: Any[1]
): Boolean [1..1]

Reference equality for reference types, value equality for value types.

Parameters
other

Other object for comparison.

Any.instance_of (
a_type: String[1]
): Any [1..1]

Create new instance of a type.

Any.type_of (
an_object: Any[1]
): String [1..1]

Type name of an object as a string. May include generic parameters, as in "Interval<Time>".

Any.not_equal alias "!=", "≠" (
other: Ordered[1]
): Boolean [1..1]

True if current object not equal to other. Returns not equal().

PATHABLE.parent (): PATHABLE [1..1]

Parent of this node in a compositional hierarchy.

PATHABLE.item_at_path (
a_path: String[1]
): Any

Pre: path_unique (a_path) [1..1]

The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item.

PATHABLE.items_at_path (
a_path: String[1]
): List<Any> [0..1]

List of items corresponding to a non-unique path.

PATHABLE.path_exists (
a_path: String[1]
): Boolean

Pre: not a_path.is_empty [1..1]

True if the path exists in the data with respect to the current item.

PATHABLE.path_unique (
a_path: String[1]
): Boolean

Pre: path_exists (a_path) [1..1]

True if the path corresponds to a single item in the data.

PATHABLE.path_of_item (
a_loc: PATHABLE[1]
): String [1..1]

The path to an item relative to the root of this archetyped structure.

concept (): DV_TEXT [1..1]

Clinical concept of the archetype as a whole (= derived from the archetype_node_id' of the root node)

is_archetype_root (): Boolean [1..1]

True if this node is the root of an archetyped structure.

Invariants

Links_valid: links /= Void implies not links.is_empty

Archetyped_valid: is_archetype_root xor archetype_details = Void

Archetype_node_id_valid: not archetype_node_id.is_empty

 
{
    "name": "LOCATABLE",
    "documentation": "Root class of all information model classes that can be archetyped. Most classes in the openEHR reference model inherit from the `LOCATABLE` class, which defines the idea of  locatability in an archetyped structure. `LOCATABLE` defines a runtime name and an `_archetype_node_id_`. ",
    "is_abstract": true,
    "ancestors": [
        "PATHABLE"
    ],
    "properties": {
        "name": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "name",
            "documentation": "Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users. \n",
            "is_mandatory": true,
            "type": "DV_TEXT"
        },
        "archetype_node_id": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "archetype_node_id",
            "documentation": "Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g.  `at0005`. This value enables a 'standardised' name for this node to be generated, by referring to the generating archetype local terminology. \n\nAt an archetype root point, the value of this attribute is always the stringified form of the `_archetype_id_` found in the `_archetype_details_` object. \n",
            "is_mandatory": true,
            "type": "String"
        },
        "uid": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "uid",
            "documentation": "Optional globally unique object identifier for root points of archetyped structures. ",
            "type": "UID_BASED_ID"
        },
        "links": {
            "_type": "P_BMM_CONTAINER_PROPERTY",
            "name": "links",
            "documentation": "Links to other archetyped structures (data whose root object inherits from `ARCHETYPED`, such as `ENTRY`, `SECTION` and so on). Links may be to structures in other compositions. ",
            "type_def": {
                "container_type": "List",
                "type": "LINK"
            },
            "cardinality": {
                "lower": 0,
                "upper_unbounded": true
            }
        },
        "archetype_details": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "archetype_details",
            "documentation": "Details of archetyping used on this node.",
            "type": "ARCHETYPED"
        },
        "feeder_audit": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "feeder_audit",
            "documentation": "Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node. ",
            "type": "FEEDER_AUDIT"
        }
    },
    "functions": {
        "concept": {
            "name": "concept",
            "documentation": "Clinical concept of the archetype as a whole (= derived from the archetype_node_id' of the root node) ",
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "DV_TEXT"
            }
        },
        "is_archetype_root": {
            "name": "is_archetype_root",
            "documentation": "True if this node is the root of an archetyped structure.",
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "Boolean"
            }
        }
    },
    "invariants": {
        "Links_valid": "links /= Void implies not links.is_empty",
        "Archetyped_valid": "is_archetype_root xor archetype_details = Void",
        "Archetype_node_id_valid": "not archetype_node_id.is_empty"
    }
}
LOCATABLE

ARCHETYPED Class

  • Definition

  • Effective

  • BMM

  • UML

Class

ARCHETYPED

Description

Archetypes act as the configuration basis for the particular structures of instances defined by the reference model. To enable archetypes to be used to create valid data, key classes in the reference model act as root points for archetyping; accordingly, these classes have the archetype_details attribute set.

An instance of the class ARCHETYPED contains the relevant archetype identification information, allowing generating archetypes to be matched up with data instances.

Attributes

Signature

Meaning

1..1

archetype_id: ARCHETYPE_ID

Globally unique archetype identifier.

0..1

template_id: TEMPLATE_ID

Globally unique template identifier, if a template was active at this point in the structure. Normally, a template would only be used at the top of a top-level structure, but the possibility exists for templates at lower levels.

1..1

rm_version: String

Version of the openEHR reference model used to create this object. Expressed in terms of the release version string, e.g. 1.0 , 1.2.4 .

Invariants

Rm_version_valid: not rm_version.is_empty
ARCHETYPED

Archetypes act as the configuration basis for the particular structures of instances defined by the reference model. To enable archetypes to be used to create valid data, key classes in the reference model act as root points for archetyping; accordingly, these classes have the archetype_details attribute set.

An instance of the class ARCHETYPED contains the relevant archetype identification information, allowing generating archetypes to be matched up with data instances.

Attributes

archetype_id: ARCHETYPE_ID [1..1]

Globally unique archetype identifier.

template_id: TEMPLATE_ID [0..1]

Globally unique template identifier, if a template was active at this point in the structure. Normally, a template would only be used at the top of a top-level structure, but the possibility exists for templates at lower levels.

rm_version: String [1..1]

Version of the openEHR reference model used to create this object. Expressed in terms of the release version string, e.g. 1.0 , 1.2.4 .

Invariants

Rm_version_valid: not rm_version.is_empty

 
{
    "name": "ARCHETYPED",
    "documentation": "Archetypes act as the configuration basis for the particular structures of instances defined by the reference model. To enable archetypes to be used to create valid data, key classes in the reference model act as  root  points for archetyping; accordingly, these classes have the `_archetype_details_` attribute set. \n\nAn instance of the class `ARCHETYPED` contains the relevant archetype identification information, allowing generating archetypes to be matched up with data instances.",
    "properties": {
        "archetype_id": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "archetype_id",
            "documentation": "Globally unique archetype identifier. ",
            "is_mandatory": true,
            "type": "ARCHETYPE_ID"
        },
        "template_id": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "template_id",
            "documentation": "Globally unique template identifier, if a template was active at this point in the structure. Normally, a template would only be used at the top of a top-level structure, but the possibility exists for templates at lower levels. ",
            "type": "TEMPLATE_ID"
        },
        "rm_version": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "rm_version",
            "documentation": "Version of the openEHR reference model used to create this object. Expressed in terms of the release version string, e.g.  1.0 ,  1.2.4 .",
            "is_mandatory": true,
            "type": "String"
        }
    },
    "invariants": {
        "Rm_version_valid": "not rm_version.is_empty"
    }
}
ARCHETYPED

LINK Class

  • Definition

  • Effective

  • BMM

  • UML

Class

LINK

Description

The LINK type defines a logical relationship between two items, such as two ENTRYs or an ENTRY and a COMPOSITION. Links can be used across compositions, and across EHRs. Links can potentially be used between interior (i.e. non archetype root) nodes, although this probably should be prevented in archetypes. Multiple LINKs can be attached to the root object of any archetyped structure to give the effect of a 1→N link.

1:1 and 1:N relationships between archetyped content elements (e.g. ENTRYs) can be expressed by using one, or more than one, respectively, LINKs. Chains of links can be used to see problem threads or other logical groupings of items.

Links should be between archetyped structures only, i.e. between objects representing complete domain concepts because relationships between sub-elements of whole concepts are not necessarily meaningful, and may be downright confusing. Sensible links only exist between whole ENTRYs, SECTIONs, COMPOSITIONs and so on.

Attributes

Signature

Meaning

1..1

meaning: DV_TEXT

Used to describe the relationship, usually in clinical terms, such as in response to (the relationship between test results and an order), follow-up to and so on. Such relationships can represent any clinically meaningful connection between pieces of information. Values for meaning include those described in Annex C, ENV 13606 pt 2 under the categories of generic , documenting and reporting , organisational , clinical , circumstancial , and view management .

1..1

type: DV_TEXT

The type attribute is used to indicate a clinical or domain-level meaning for the kind of link, for example problem or issue . If type values are designed appropriately, they can be used by the requestor of EHR extracts to categorise links which must be followed and which can be broken when the extract is created.

1..1

target: DV_EHR_URI

The logical to object in the link relation, as per the linguistic sense of the meaning attribute.
LINK

The LINK type defines a logical relationship between two items, such as two ENTRYs or an ENTRY and a COMPOSITION. Links can be used across compositions, and across EHRs. Links can potentially be used between interior (i.e. non archetype root) nodes, although this probably should be prevented in archetypes. Multiple LINKs can be attached to the root object of any archetyped structure to give the effect of a 1→N link.

1:1 and 1:N relationships between archetyped content elements (e.g. ENTRYs) can be expressed by using one, or more than one, respectively, LINKs. Chains of links can be used to see problem threads or other logical groupings of items.

Links should be between archetyped structures only, i.e. between objects representing complete domain concepts because relationships between sub-elements of whole concepts are not necessarily meaningful, and may be downright confusing. Sensible links only exist between whole ENTRYs, SECTIONs, COMPOSITIONs and so on.

Attributes

meaning: DV_TEXT [1..1]

Used to describe the relationship, usually in clinical terms, such as in response to (the relationship between test results and an order), follow-up to and so on. Such relationships can represent any clinically meaningful connection between pieces of information. Values for meaning include those described in Annex C, ENV 13606 pt 2 under the categories of generic , documenting and reporting , organisational , clinical , circumstancial , and view management .

type: DV_TEXT [1..1]

The type attribute is used to indicate a clinical or domain-level meaning for the kind of link, for example problem or issue . If type values are designed appropriately, they can be used by the requestor of EHR extracts to categorise links which must be followed and which can be broken when the extract is created.

target: DV_EHR_URI [1..1]

The logical to object in the link relation, as per the linguistic sense of the meaning attribute.

 
{
    "name": "LINK",
    "documentation": "The `LINK` type defines a logical relationship between two items, such as two `ENTRYs` or an `ENTRY` and a `COMPOSITION`. Links can be used across compositions, and across EHRs. Links can potentially be used between interior (i.e. non archetype root) nodes, although this probably should be prevented in archetypes. Multiple `LINKs` can be attached to the root object of any archetyped structure to give the effect of a 1->N link.\n\n1:1 and 1:N relationships between archetyped content elements (e.g. `ENTRYs`) can be expressed by using one, or more than one, respectively, `LINKs`. Chains of links can be used to see  problem threads  or other logical groupings of items. \n\nLinks should be between archetyped structures only, i.e. between objects representing complete domain concepts because relationships between sub-elements of whole concepts are not necessarily meaningful, and may be downright confusing. Sensible links only exist between whole `ENTRYs`, `SECTIONs`, `COMPOSITIONs` and so on. ",
    "properties": {
        "meaning": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "meaning",
            "documentation": "Used to describe the relationship, usually in clinical terms, such as  in response to  (the relationship between test results and an order),  follow-up to  and so on. Such relationships can represent any clinically meaningful connection between pieces of information. Values for meaning include those described in Annex C, ENV 13606 pt 2 under the categories of  generic ,  documenting and reporting ,  organisational ,  clinical ,  circumstancial , and  view management .",
            "is_mandatory": true,
            "type": "DV_TEXT"
        },
        "type": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "type",
            "documentation": "The type attribute is used to indicate a clinical or domain-level meaning for the kind of link, for example  problem  or  issue . If type values are designed appropriately, they can be used by the requestor of EHR extracts to categorise links which must be followed and which can be broken when the extract is created. \n",
            "is_mandatory": true,
            "type": "DV_TEXT"
        },
        "target": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "target",
            "documentation": "The logical  to  object in the link relation, as per the linguistic sense of the meaning attribute.",
            "is_mandatory": true,
            "type": "DV_EHR_URI"
        }
    }
}
LINK

FEEDER_AUDIT Class

  • Definition

  • Effective

  • BMM

  • UML

Class

FEEDER_AUDIT

Description

The FEEDER_AUDIT class defines the semantics of an audit trail which is constructed to describe the origin of data that have been transformed into openEHR form and committed to the system.

Attributes

Signature

Meaning

0..1

originating_system_item_ids: List<DV_IDENTIFIER>

Identifiers used for the item in the originating system, e.g. filler and placer ids.

0..1

feeder_system_item_ids: List<DV_IDENTIFIER>

Identifiers used for the item in the feeder system, where the feeder system is distinct from the originating system.

0..1

original_content: DV_ENCAPSULATED

Optional inline inclusion of or reference to original content corresponding to the openEHR content at this node. Typically a URI reference to a document or message in a persistent store associated with the EHR.

1..1

originating_system_audit: FEEDER_AUDIT_DETAILS

Any audit information for the information item from the originating system.

0..1

feeder_system_audit: FEEDER_AUDIT_DETAILS

Any audit information for the information item from the feeder system, if different from the originating system.
FEEDER_AUDIT

The FEEDER_AUDIT class defines the semantics of an audit trail which is constructed to describe the origin of data that have been transformed into openEHR form and committed to the system.

Attributes

originating_system_item_ids: List<DV_IDENTIFIER> [0..1]

Identifiers used for the item in the originating system, e.g. filler and placer ids.

feeder_system_item_ids: List<DV_IDENTIFIER> [0..1]

Identifiers used for the item in the feeder system, where the feeder system is distinct from the originating system.

original_content: DV_ENCAPSULATED [0..1]

Optional inline inclusion of or reference to original content corresponding to the openEHR content at this node. Typically a URI reference to a document or message in a persistent store associated with the EHR.

originating_system_audit: FEEDER_AUDIT_DETAILS [1..1]

Any audit information for the information item from the originating system.

feeder_system_audit: FEEDER_AUDIT_DETAILS [0..1]

Any audit information for the information item from the feeder system, if different from the originating system.

 
{
    "name": "FEEDER_AUDIT",
    "documentation": "The `FEEDER_AUDIT` class defines the semantics of an audit trail which is constructed to describe the origin of data that have been transformed into openEHR form and committed to the system. ",
    "properties": {
        "originating_system_item_ids": {
            "_type": "P_BMM_CONTAINER_PROPERTY",
            "name": "originating_system_item_ids",
            "documentation": "Identifiers used for the item in the originating system, e.g. filler and placer ids. ",
            "type_def": {
                "container_type": "List",
                "type": "DV_IDENTIFIER"
            },
            "cardinality": {
                "lower": 0,
                "upper_unbounded": true
            }
        },
        "feeder_system_item_ids": {
            "_type": "P_BMM_CONTAINER_PROPERTY",
            "name": "feeder_system_item_ids",
            "documentation": "Identifiers used for the item in the feeder system, where the feeder system is distinct from the originating system. ",
            "type_def": {
                "container_type": "List",
                "type": "DV_IDENTIFIER"
            },
            "cardinality": {
                "lower": 0,
                "upper_unbounded": true
            }
        },
        "original_content": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "original_content",
            "documentation": "Optional inline inclusion of or reference to original content corresponding to the openEHR content at this node. Typically a URI reference to a document or message in a persistent store associated with the EHR. ",
            "type": "DV_ENCAPSULATED"
        },
        "originating_system_audit": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "originating_system_audit",
            "documentation": "Any audit information for the information item from the originating system. ",
            "is_mandatory": true,
            "type": "FEEDER_AUDIT_DETAILS"
        },
        "feeder_system_audit": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "feeder_system_audit",
            "documentation": "Any audit information for the information item from the feeder system, if different from the originating system.",
            "type": "FEEDER_AUDIT_DETAILS"
        }
    }
}
FEEDER_AUDIT

FEEDER_AUDIT_DETAILS Class

  • Definition

  • Effective

  • BMM

  • UML

Class

FEEDER_AUDIT_DETAILS

Description

Audit details for any system in a feeder system chain. Audit details here means the general notion of who/where/when the information item to which the audit is attached was created. None of the attributes is defined as mandatory, however, in different scenarios, various combinations of attributes will usually be mandatory. This can be controlled by specifying feeder audit details in legacy archetypes.

Attributes

Signature

Meaning

1..1

system_id: String

Identifier of the system which handled the information item. This is the IT system owned by the organisation legally responsible for handling the data, and at which the data were previously created or passed by an earlier system.

0..1

location: PARTY_IDENTIFIED

Identifier of the particular site/facility within an organisation which handled the item. For computability, this identifier needs to be e.g. a PKI identifier which can be included in the identifier list of the PARTY_IDENTIFIED object.

0..1

subject: PARTY_PROXY

Identifiers for subject of the received information item.

0..1

provider: PARTY_IDENTIFIED

Optional provider(s) who created, committed, forwarded or otherwise handled the item.

0..1

time: DV_DATE_TIME

Time of handling the item. For an originating system, this will be time of creation, for an intermediate feeder system, this will be a time of accession or other time of handling, where available.

0..1

version_id: String

Any identifier used in the system such as "interim" , "final" , or numeric versions if available.

0..1

other_details: ITEM_STRUCTURE

Optional attribute to carry any custom meta-data. May be archetyped.

Invariants

System_id_valid: not system_id.is_empty
FEEDER_AUDIT_DETAILS

Audit details for any system in a feeder system chain. Audit details here means the general notion of who/where/when the information item to which the audit is attached was created. None of the attributes is defined as mandatory, however, in different scenarios, various combinations of attributes will usually be mandatory. This can be controlled by specifying feeder audit details in legacy archetypes.

Attributes

system_id: String [1..1]

Identifier of the system which handled the information item. This is the IT system owned by the organisation legally responsible for handling the data, and at which the data were previously created or passed by an earlier system.

location: PARTY_IDENTIFIED [0..1]

Identifier of the particular site/facility within an organisation which handled the item. For computability, this identifier needs to be e.g. a PKI identifier which can be included in the identifier list of the PARTY_IDENTIFIED object.

subject: PARTY_PROXY [0..1]

Identifiers for subject of the received information item.

provider: PARTY_IDENTIFIED [0..1]

Optional provider(s) who created, committed, forwarded or otherwise handled the item.

time: DV_DATE_TIME [0..1]

Time of handling the item. For an originating system, this will be time of creation, for an intermediate feeder system, this will be a time of accession or other time of handling, where available.

version_id: String [0..1]

Any identifier used in the system such as "interim" , "final" , or numeric versions if available.

other_details: ITEM_STRUCTURE [0..1]

Optional attribute to carry any custom meta-data. May be archetyped.

Invariants

System_id_valid: not system_id.is_empty

 
{
    "name": "FEEDER_AUDIT_DETAILS",
    "documentation": "Audit details for any system in a feeder system chain. Audit details here means the general notion of who/where/when the information item to which the audit is attached was created. None of the attributes is defined as mandatory, however, in different scenarios, various combinations of attributes will usually be mandatory. This can be controlled by specifying feeder audit details in legacy archetypes. ",
    "properties": {
        "system_id": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "system_id",
            "documentation": "Identifier of the system which handled the information item. This is the IT system owned by the organisation legally responsible for handling the data, and at which the data were previously created or passed by an earlier system.\n",
            "is_mandatory": true,
            "type": "String"
        },
        "location": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "location",
            "documentation": "Identifier of the particular site/facility within an organisation which handled the item. For computability, this identifier needs to be e.g. a PKI identifier which can be included in the identifier list of the `PARTY_IDENTIFIED` object. ",
            "type": "PARTY_IDENTIFIED"
        },
        "subject": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "subject",
            "documentation": "Identifiers for subject of the received information item. ",
            "type": "PARTY_PROXY"
        },
        "provider": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "provider",
            "documentation": "Optional provider(s) who created, committed, forwarded or otherwise handled the item. ",
            "type": "PARTY_IDENTIFIED"
        },
        "time": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "time",
            "documentation": "Time of handling the item. For an originating system, this will be time of creation, for an intermediate feeder system, this will be a time of accession or other time of handling, where available.",
            "type": "DV_DATE_TIME"
        },
        "version_id": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "version_id",
            "documentation": "Any identifier used in the system such as  \"interim\" ,  \"final\" , or numeric versions if available. ",
            "type": "String"
        },
        "other_details": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "other_details",
            "documentation": "Optional attribute to carry any custom meta-data. May be archetyped.",
            "type": "ITEM_STRUCTURE"
        }
    },
    "invariants": {
        "System_id_valid": "not system_id.is_empty"
    }
}
FEEDER_AUDIT_DETAILS