Changes between Initial Version and Version 1 of Support Information Model 4 Identification Package


Ignore:
Timestamp:
Aug 27, 2008, 8:30:23 PM (16 years ago)
Author:
KOBAYASHI, Shinji
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Support Information Model 4 Identification Package

    v1 v1  
     1== Identification Package == #LinkTarget_17411
     2=== 4.1 Overview === #LinkTarget_17413
     3The rm.support.identification package describes a model of references and identifiers for information entities and is illustrated in [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_17418 FIGURE 5] .
     4
     5identification
     6
     7FIGURE 5  rm.support.identification Package
     8
     9=== 4.1.1 Requirements === #LinkTarget_17420
     10Identification of entities both in the real world and in information systems is a non-trivial problem. The needs for identification across systems in a health information environment include the following:
     11
     12 * real world identifiers such as social security numbers, veterans affairs ids etc can be recorded as required by health care facilities, enterprise policies, or legislation;
     13 * identifiers for informational entities which represent real world entities or processes should be unique;
     14 * it should be possible to determine if two identifiers refer to information entities that represent the same real world entity, even if instances of the information entities are maintained in different systems;
     15 * versions or changes to real-world entity-linked informational entities (which may create new information instances) should be accounted for in two ways:
     16
     17[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 33 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     18
     19  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     20
     21Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     22
     23-        it should be possible to tell if two identifiers refer to distinct versions of the same
     24
     25informational entity in the same version tree;
     26
     27-        it should not be possible to confuse same-named versions of informational entities
     28
     29maintained in multiple systems which purport to represent the same real world
     30
     31entity. E.g. there is no guarantee that two systems’ “latest” version of the Person
     32
     33“Dr Jones” is the same.
     34
     35Medico-legal use of information relies on previous states of information being
     36
     37distinguishable from other previous states and the current state.
     38
     39•         It should be possible for an entity in one system or service (such as the EHR) to refer to an entity in another system or service in such a way that: -the target of the reference is easily finable within the shared environment, and
     40
     41-        the reference does is valid regardless of the physical architecture of servers and applications.
     42
     43The following subsections describe some of the features and challenges of identification.
     44
     45Identification of Real World Entities (RWEs)
     46
     47Real world entities such as people, car engines, invoices, and appointments can all be assigned identifiers. Although many of these are designed to be unique within a jurisdiction, they are often not, due to data entry errors, bad design (ids that are too small or incorporate some non-unique characteristic of the identified entities), bad process (e.g. non-synchronised id issuing points); identity theft (e.g. via theft of documents of proof or hacking). In general, while some real world identifiers (RWIs) are “nearly unique”, none can be guaranteed so. It should also be the case that if two RWE identifiers are equal, they refer to the same RWE, but this is often not the case. For practical purposes, RWIs cannot be regarded as computationally safe for making the inferences described here.
     48
     49Identification of Informational Entities (IEs)
     50
     51As soon as information systems are used to record facts about RWEs, the situation becomes more complex because of the intangible nature of information. In particular:
     52
     53 * the same RWE can be represented simultaneously on more than one system (‘spatial multiplicity’);
     54 * the same RWE may be represented by more than one “version” of the same IE in a system (‘temporal multiplicity’).
     55
     56At first sight, it appears that there can also be purely informational entities, i.e. IEs which do not refer to any RWE, such as books, online-only documents and software. However, as soon as one considers an example it becomes clear that there is always a notional ‘definitive’ or ‘authoritative’ (i.e. trusted) version of every such entity. These entities can better be understood as ‘virtual RWEs’. Thus it can still be said that multiple IEs may refer to any given RWE.
     57
     58The underlying reason for the multiplicity of IEs is that ‘reality’ - time and space - in computer systems is not continuous but discrete, and each ‘entity’ is in fact just a snapshot of certain attribute values of a RWE, at a point in time, in a particular system. If identifiers are assigned to IEs without regard to versions or duplicates, then no assertion can be made about the identified RWE when two IE ids are compared.
     59
     60Identification of Versions
     61
     62The notion of ‘versioning’ applies only to informational entities, i.e. distinct instances of content each representing a snapshot of some logical entity. Where such instances are stored and managed in versioned containers within a versioning system of some kind, explicit identification of the versions is
     63
     64Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 34 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     65
     66[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     67
     68[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     69
     70required. The requirements are discussed in detail in the Common IM, change_control package. They can be summarised as follows:
     71
     72 * it must be possible to distinguish two versions of the same logical entity, i.e. know from the identifier if they are the same or different versions of the same thing;
     73 * it must be possible to distinguish two versions of the same logical entity created in two distinct systems;
     74 * it must be possible to tell the relationship between the items in a versioned lineage, from the version identifiers.
     75
     76Referencing of Informational Entities
     77
     78Within a distributed information environment, there is a need for entities not connected by direct references in the same memory space to be able to refer to each other. There are two competing requirements:
     79
     80 * that the separation of objects in a distributed computing environment not compromise the semantics of the model;
     81 * that different types of information can be managed relatively independently; for example EHR and demographic information can be managed by different groups in an organisation or community, each with at least some freedom to change implementation and model details.
     82
     83=== 4.2 Design === #LinkTarget_17533
     84This package models only informational identifiers, i.e. transparent identifiers understood by openEHR or related computational systems. Real World Entity Identifiers such as driver’s license numbers are modelled using the data type DV_IDENTIFIER. This is not to imply that such identifiers are any less systematic or well-managed than the system identifiers defined here, only that from the point of view of openEHR, they have the same status as other informational attributes such as name, address etc of a Person.
     85
     86A key design decision has been to choose a string representation for all identifiers, with subparts being made available by appropriate functions which perform simple parsing on the string. This ensures that the data representation of identifiers (e.g. in XML) is as small as possible, while not losing object-oriented typing.
     87
     88=== 4.2.1 Primitive Identifiers === #LinkTarget_17538
     89Three kinds of types are defined in this package. The abstract UIDtype and its subtypes correspond to permanent, computationally reliable, primitive identifiers. Such identifiers are regarded as ‘primitive’ because they are treated as having no further internal structure, in the sense that part of such an identifier is not in general meaningful. The three subtypes UUID, ISO_OID and INTERNET_ID all have these properties, and are commonly accepted ways of uniquely identifying entities in computer systems. In openEHR (and generally in health informatics) they are usually used as parts of other identifiers.
     90
     91A consequence of the string representation approach used in these classes is that to set an attribute of type UID from a string value, as would be done when reading from a database, deserialising from XML or another text form, a piece of code that inspects the string structure has to be used in order to decide which of the subtypes of UID it is. This is a safe thing to do, since all three subtypes have mutually exclusive string patterns, and can easily be distinguished.
     92
     93[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 35 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     94
     95  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     96
     97Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     98
     99=== 4.2.2 Composite Identifiers === #LinkTarget_17560
     100The OBJECT_ID type and its hierarchy of subtypes correspond to composite identifier types whose structure and semantics are defined by openEHR (rather than external organisations), and are the main means of identifying information items in an openEHR system. The abstract type UID_BASED_IDand its two subtypes HIER_OBJECT_IDand OBJECT_VERSION_IDprovide respectively, UID-based identifiers for non-versioned and versioned items. The design of the latter subtype is explained in the openEHR Common IM, change_control package.
     101
     102The other subtypes, ARCHETYPE_ID and TERMINOLOGY_ID define different kinds of identifier, the former being a multi-axial identifier for archetypes, and the latter being a globally unique single string identifier for terminologies. The ARCHETYPE_ID class explicitly includes archetype version as part of the identifier, while terminology identifier values are assumed to include this, either as part of the name (e.g. as is done in the US National Library of Medicine UMLS identifiers - see http://www.nlm.nih.gov/research/umls/metaa1.html ), or according to the syntax defined in [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_18094 section 4.3.12]  below.
     103
     104Identifying Versions
     105
     106The OBJECT_VERSION_ID defines the semantics of the scheme used in openEHR for identifying versions, and uses a three-part identifier, consisting of:
     107
     108•         object_id: the identifier of the version container, in the form of an UID;
     109
     110 * version_tree_id: the location in the version tree, as a 1- or 3-part numeric identifier, where the latter variant expresses branching; this is modelled using the VERSION_TREE_ID type;
     111 * creating_system_id: the identifier of the system in which this version was created, or type UID.
     112
     113Under this scheme, multiple versions in the same container all have the same value for object_id, while their location in the version tree is given by the combination of the version tree identifier and the identifier of the creating system.
     114
     115The requirements on the third part of the identifier are that it be unique per system, and that it be easy to obtain or generate. It is also helpful if it is a meaningful identifier. The two most practical candidates appear to be GUIDs (which are not meaningful, but are easy to generate) and reverse internet  domain identifiers, as recommended in ![3] (these are easy to determine if the system has an internet  address, and are meaningful and directly processible, however unconnected systems pose a problem). ISO Oids might also be used. All of these identifier types are accommodated via the use of UID.
     116
     117A full explanation of the version identification scheme and its capabilities is given in the change_control section of the Common IM.
     118
     119=== 4.2.3 References === #LinkTarget_17585
     120All OBJECT_IDs are used as identifier attributes within the thing they identify, in the same way as a database primary key. To refer to an identified object from another object, an instance of the class OBJECT_REF should generally be used, in the same way as a database foreign key. The class OBJECT_REF is provided as a means of distributed referencing, and includes the object namespace (typically !1:1 with some service, such as “terminology”) and type. The general principle of object references is to be able to refer to an object available in a particular namespace or service. Usually they are used to refer to objects in other services, such as a demographic entity from within an EHR, but they may be used to refer to local objects as well. The type may be the concrete type of the referred-to object (e.g. “GP”) or any proper ancestor (e.g. “PARTY”).
     121
     122Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 36 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     123
     124[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     125
     126[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     127
     1284.3 Class Descriptions
     129
     1304.3.1 UID Class
     131
     132||CLASS||UID (abstract)||
     133||Purpose||Abstract parent of classes representing unique identifiers which identify information entities in a durable way. UIDs only ever identify one IE in time or space and are never re-used.||
     134||HL7||The HL7v3 UID Data type.||
     135||Attributes||Signature||Meaning||
     136||||value: String||The value of the id.||
     137||Invariant||Value_exists: value /= Void and then not value.empty||
     138
     1394.3.2 ISO_OID Class
     140
     141||CLASS||ISO_OID||
     142||Purpose||Model of ISO’s Object Identifier (oid) as defined by the standard ISO/IEC 8824 . Oids are formed from integers separated by dots. Each non-leaf node in an Oid starting from the left corresponds to an assigning authority, and identifies that authority’s namespace, inside which the remaining part of the identifier is locally unique.||
     143||HL7||The HL7v3 OID Data type.||
     144||Inherit||UID||
     145||Functions||Signature||Meaning||
     146||Invariant||||
     147
     1484.3.3 UUID Class
     149
     150||CLASS||UUID||
     151||Purpose||Model of the DCE Universal Unique Identifier or UUID which takes the form of hexadecimal integers separated by hyphens, following the pattern 8-4-4-4-12 as defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. Also known as a GUID.||
     152||HL7||The HL7v3 UUID Data type.||
     153||Inherit||UID||
     154
     155[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 37 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     156
     157  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     158
     159Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     160
     161||CLASS||||UUID||||
     162||Functions||Signature||||Meaning||
     163||Invariant||||||||
     164
     1654.3.4 INTERNET_ID Class
     166
     167||CLASS||INTERNET_ID||
     168||Purpose||[http://www.ietf.org/rfc/rfc1034.txt Model[[BR]]of a reverse internet domain, as used to uniquely identify an internet[[BR]]domain. In the form of a dot-separated string in the reverse order of a[[BR]]domain name, specified by IETF RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt).]||
     169||Inherit||UID||
     170||Functions||Signature||Meaning||
     171||Invariant||||
     172
     1734.3.4.1 Syntax
     174
     175According to IETF RFC1034, the syntax of a domain name follows the BNF grammar:
     176
     177domain: subdomain | ‘ ’ subdomain: label | subdomain ‘.’ label  label: letter [ [ ldh-str ] let-dig ] ldh-str: let-dig-hyp | let-dig-hyp ldh-str let-dig-hyp: let-dig | ‘-’ let-dig: letter | digit
     178
     179letter: any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
     180
     181digit: any one of the ten digits 0 through 9
     182
     183It can also be expressed using the regular expression:
     184
     185[a-zA-Z]([a-zA-Z0-9-]*[a-zA-Z0-9])?(\.[a-zA-Z]([a-zA-Z0-9-]*[a-zA-Z0-9]))*
     186
     1874.3.5 OBJECT_ID Class
     188
     189||CLASS||OBJECT_ID (abstract)||
     190||Purpose||Ancestor class of identifiers of informational objects. Ids may be completely meaningless, in which case their only job is to refer to something, or may carry some information to do with the identified object.||
     191||Use||Object ids are used inside an object to identify that object. To identify another object in another service, use an OBJECT_REF, or else use a UID for local objects identified by UID. If none of the subtypes is suitable, direct instances of this class may be used.||
     192
     193Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 38 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     194
     195[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     196
     197[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     198
     199||CLASS||OBJECT_ID (abstract)||
     200||Attributes||Signature||Meaning||
     201||||value: String||The value of the id in the form defined below.||
     202||Invariant||Value_exists: value /= Void and then not value.empty||
     203
     2044.3.6 UID_BASED_ID Class
     205
     206||CLASS||UID_BASED_ID (abstract)||
     207||Purpose||Abstract model of UID-based identifiers consisting of a root part and an optional extension; lexical form: root ‘::’ extension||
     208||Inherit||''OBJECT_ID ''||
     209||Functions||Signature||Meaning||
     210||1..1||root: UID||The identifier of the conceptual namespace in which the object exists, within the identification scheme. Returns the part to the left of the first ‘::’ separator, if any, or else the whole string.||
     211||1..1||extension: String||Optional local identifier of the object within the context of the root identifier. Returns the part to the right of the first ‘::’ separator if any, or else any empty String.||
     212||||has_extension: Boolean||True if extension /= Void||
     213||Invariant||Root_valid: root /= Void Extension_validity: extension /= Void Has_extension_validity: extension.is_empty xor has_extension||
     214
     215==== 4.3.6.1 Identifier Syntax ==== #LinkTarget_17794
     216The syntax of the value attribute by default follows the following production rules (EBNF):
     217
     218value: root [ ‘::’ extension ] root: uid -- see UID above extension: string
     219
     2204.3.7 HIER_OBJECT_ID Class
     221
     222Concrete type corresponding to hierarchical identifiers of the form defined by UID_BASED_ID.
     223
     224[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 39 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     225
     226  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     227
     228Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     229
     230||CLASS||HIER_OBJECT_ID||
     231||HL7||The HL7v3 II Data type.||
     232||Inherit||''UID_BASED_ID ''||
     233||Functions||Signature||Meaning||
     234||Invariant||||
     235
     2364.3.8 OBJECT_VERSION_ID Class
     237
     238||CLASS||OBJECT_VERSION_ID||
     239||Purpose||Globally unique identifier for one version of a versioned object; lexical form: object_id ‘::’ creating_system_id ‘::’ version_tree_id||
     240||Inherit||''UID_BASED_ID ''||
     241||Functions||Signature||Meaning||
     242||1..1||object_id: UID||Unique identifier for logical object of which this identifier identifies one version; normally the object_id will be the unique identifier of the version container containing the version referred to by this OBJECT_VERSION_ID instance.||
     243||1..1||version_tree_id: VERSION_TREE_ID||Tree identifier of this version with respect to other versions in the same version tree, as either 1 or 3 part dot-separated numbers, e.g. “1”, “2.1.4”.||
     244||1..1||creating_system_id: UID||Identifier of the system that created the Version corresponding to this Object version id.||
     245||||is_branch: Boolean||True if this version identifier represents a branch.||
     246||Invariants||Object_valid: object_id /= Void Version_tree_id_valid: version_tree_id /= Void creating_system_id_valid: creating_system_id /= Void||
     247
     2484.3.8.1 Identifier Syntax
     249
     250The string form of an OBJECT_VERSION_ID stored in its value attribute consists of three segments separated by double colons (“::”), i.e. (EBNF):
     251
     252value: object_id ‘::’ creating_system_id ‘::’ version_tree_id object_id: uid -- see UID below creating_system_id:
     253
     254Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 40 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     255
     256[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     257
     258[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     259
     260An example is as follows:
     261
     262F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC::87284370-2D4B4e3d-A3F3-F303D2F4F34B::2
     263
     2644.3.9 VERSION_TREE_ID Class
     265
     266||CLASS||VERSION_TREE_ID||
     267||Purpose||Version tree identifier for one version. Lexical form: trunk_version [ ‘.’ branch_number ‘.’ branch_version ]||
     268||Attributes||Signature||Meaning||
     269||1..1||value: String||String form of this identifier.||
     270||Functions||Signature||Meaning||
     271||1..1||trunk_version: String||Trunk version number; numbering starts at 1.||
     272||0..1||branch_number: String||Number of branch from the trunk point; numbering starts at 1.||
     273||0..1||branch_version: String||Version of the branch; numbering starts at 1.||
     274||1..1||is_branch: Boolean||True if this version identifier represents a branch, i.e. has branch_number and branch_version parts.||
     275||1..1||is_first: Boolean||True if this version identifier corresponds to the first version, i.e. trunk_version = “1”||
     276||Invariants||Value_valid: value /= Void and then not value.is_empty Trunk_version_valid: trunk_version /= Void and then trunk_version.is_integer and then trunk_version.as_integer >= 1 Branch_number_valid: branch_number /= Void implies branch_number.is_integer and then branch_number.as_integer >= 1 Branch_version_valid: branch_version /= Void implies branch_version.is_integer and then branch_version.as_integer >= 1 Branch_validity: (branch_number = Void and branch_version = Void ) xor (branch_number /= Void and branch_version /= Void ) Is_branch_validity: is_branch xor branch_number = Void Is_first_validity: not is_first xor trunk_version.is_equal(“1”)||
     277
     2784.3.9.1 Syntax
     279
     280The format of the value attribute is (EBNF):
     281
     282value: trunk_version [ ‘.’ branch_number ‘.’ branch_version ] trunk_version: { digit }+  branch_number: { digit }+  branch_version: { digit }+
     283
     284[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 41 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     285
     286  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     287
     288Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     289
     2904.3.10 ARCHETYPE_ID Class
     291
     292||CLASS||ARCHETYPE_ID||
     293||Purpose||Identifier for archetypes. Lexical form: rm_originator ‘-’ rm_name ‘-’ rm_entity ‘.’ concept_name { ‘-’ specialisation }* ‘.v’ number||
     294||Inherit||''OBJECT_ID ''||
     295||Functions||Signature||Meaning||
     296||1..1||qualified_rm_entity: String||Globally qualified reference model entity, e.g. “openehr-composition-OBSERVATION”.||
     297||1..1||domain_concept: String||Name of the concept represented by this archetype, including specialisation, e.g. “biochemistry_result-cholesterol”.||
     298||1..1||rm_originator: String||Organisation originating the reference model on which this archetype is based, e.g. “openehr”, “cen”, “hl7”.||
     299||1..1||rm_name: String||Name of the reference model, e.g. “rim”, “ehr_rm”, “en13606”.||
     300||1..1||rm_entity: String||Name of the ontological level within the reference model to which this archetype is targeted, e.g. for openEHR, “folder”, “composition”, “section”, “entry”.||
     301||1..1||specialisation: String||Name of specialisation of concept, if this archetype is a specialisation of another archetype, e.g. “cholesterol”.||
     302||1..1||version_id: String||Version of this archetype.||
     303||Invariant||Qualified_rm_entity_valid: qualified_rm_entity /= Void and then not qualified_rm_entity.is_empty Domain_concept_valid: domain_concept /= Void and then not domain_concept.is_empty Rm_originator_valid: rm_originator /= Void and then not rm_originator.is_empty Rm_name_valid: rm_name /= Void and then not rm_name.is_empty Rm_entity_valid: rm_entity /= Void and then not rm_entity.is_empty Specialisation_valid: specialisation /= Void implies not specialisation.is_empty Version_id_valid: version_id /= Void and then not version_id.is_empty||
     304
     305Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 42 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     306
     307[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     308
     309[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     310
     3114.3.10.1 Archetype ID Syntax
     312
     313Archetype identifiers are “multi-axial”, meaning that each identifier instance denotes a single archetype within a multi-dimensional space. In this case, the space is essentially a versioned 3-dimensional space, with the dimensions being:
     314
     315 * reference model entity, i.e. target of archetype
     316 * domain concept
     317 * version
     318
     319As with any multi-axial identifier, the underlying principle of an archetype id is that all parts of the id must be able to be considered immutable. This means that no variable characteristic of an archetype
     320
     321(e.g. accrediting authority, which might change due to later accreditation by another authority, or may be multiple) can be included in its identifier. The syntax of an ARCHETYPE_ID is as follows (EBNF):
     322
     323archetype_id: qualified_rm_entity ‘.’ domain_concept ‘.’ version_id
     324
     325qualified_rm_entity: rm_originator ‘-’ rm_name ‘-’ rm_entity  rm_originator: V_NAME  rm_name: V_NAME  rm_entity: V_NAME
     326
     327domain_concept: concept_name { ‘-’ specialisation }*  concept_name: V_NAME  specialisation: V_NAME
     328
     329version_id: ‘v’ V_NUMBER
     330
     331NUMBER: ![0-9]*  NAME: [a-z][a-z0-9()/%$#&]*
     332
     333The field meanings are as follows:
     334
     335rm_originator: id of organisation originating the reference model on which this archetype is based;
     336
     337rm_name: id of the reference model on which the archetype is based;
     338
     339rm_entity: ontological level in the reference model;
     340
     341domain_concept: the domain concept name, including any specialisations;
     342
     343version_id: numeric version identifier;
     344
     345Examples of archetype identifiers include:
     346
     347• openehr-composition-SECTION.physical_examination.v2 • openehr-composition-SECTION.physical_examination-prenatal.v1
     348
     349• hl7-rim-act.progress_note.v1 • openehr-composition-OBSERVATION.progress_note-naturopathy.v2
     350
     351Archetypes can also be identified by other means, such as ISO oids.
     352
     3534.3.11 TEMPLATE_ID Class
     354
     355Identifier for templates. Lexical form to be determined.
     356
     357[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 43 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     358
     359  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     360
     361Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     362
     363||CLASS||||TEMPLATE_ID||||
     364||Inherit||''OBJECT_ID ''||||||
     365||Functions||Signature||||||Meaning||
     366||Invariant||||||||
     367
     3684.3.12 TERMINOLOGY_ID Class
     369
     370||CLASS||TERMINOLOGY_ID||
     371||Purpose||Identifier for terminologies such accessed via a terminology query service. In this class, the value attribute identifies the Terminology in the terminology service, e.g. “SNOMED-CT”. A terminology is assumed to be in a particular language, which must be explicitly specified. The value if the id attribute is the precise terminology id identifier, including actual release (i.e. actual “version”), local modifications etc; e.g. “ICPC2”. Lexical form: name [ ‘(’ version ‘)’ ]||
     372||Inherit||''OBJECT_ID ''||
     373||Functions||Signature||Meaning||
     374||1..1||name: String||Return the terminology id (which includes the “version” in some cases). Distinct names correspond to distinct (i.e. non-compatible) terminologies. Thus the names “ICD10AM” and “ICD10” refer to distinct terminologies.||
     375||1..1||version_id: String||Version of this terminology, if versioning supported, else the empty string.||
     376||Invariants||Name_valid: name /= Void and then not name.is_empty Version_id_valid: version_id /= Void||
     377
     3784.3.12.1 Identifier Syntax
     379
     380The syntax of the value attribute is as follows:
     381
     382name [ ‘(’ version ‘)’ ]
     383
     384Examples of terminology identifiers include:
     385
     386 * “snomed-ct”
     387 * “ICD9(1999)”
     388
     389Versions should only be needed for those terminologies which break the rule that the thing being identified with a code loses or changes its meaning over versions of the terminology. This should not be the case for well known modern terminologies and ontologies, particularly those designed since the publication of Cimino’s ‘desiderata’ [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19407 "[1]"]  of which the principle of “concept permanance” is appli-
     390
     391Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 44 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     392
     393[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     394
     395[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     396
     397cable here - “A concept's meaning cannot change and it cannot be deleted from the vocabulary”. However, there maybe older terminologies, or specialised terminologies which may not have obeyed these rules, but which are still used; version ids should always be used for these.
     398
     3994.3.13 GENERIC_ID Class
     400
     401||CLASS||GENERIC_ID||
     402||Purpose||Generic identifier type for identifiers whose format is othterwise unknown to openEHR. Includes an attribute for naming the identification scheme (which may well be local).||
     403||Inherit||''OBJECT_ID ''||
     404||attributes||Signature||Meaning||
     405||1..1||scheme: String||Name of the scheme to which this identifier conforms. Ideally this name will be recognisable globally but realistically it may be a local ad hoc scheme whose name is not controlled or standardised in any way.||
     406||Invariants||Scheme_valid: scheme /= Void and then not scheme.is_empty||
     407
     4084.3.14 OBJECT_REF Class
     409
     410||CLASS||OBJECT_REF||
     411||Purpose||Class describing a reference to another object, which may exist locally or be maintained outside the current namespace, e.g. in another service. Services are usually external, e.g. available in a LAN (including on the same host) or the internet via Corba, SOAP, or some other distributed protocol. However, in small systems they may be part of the same executable as the data containing the Id.||
     412||Attributes||Signature||Meaning||
     413||1..1||id: ''OBJECT_ID ''||Globally unique id of an object, regardless of where it is stored.||
     414||1..1||namespace: String||Namespace to which this identifier belongs in the local system context (and possibly in any other openEHR compliant environment) e.g. “terminology”, “demographic”. These names are not yet standardised. Legal values for the namespace are “local” | “unknown” | “[a-zAZ]![a-zA-Z0-9_-:/&+?]*”||
     415
     416[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 45 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     417
     418  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     419
     420Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     421
     422||CLASS||OBJECT_REF||
     423||1..1||type: String||Name of the class (concrete or abstract) of object to which this identifier type refers, e.g. “PARTY”, “PERSON”, “GUIDELINE” etc. These class names are from the relevant reference model. The type name “ANY” can be used to indicate that any type is accepted (e.g. if the type is unknown).||
     424||Invariant||Id_exists: id /= Void Namespace_exists: namespace /= Void and then not namespace.is_empty Type_exists: type /= Void and then not type.is_empty||
     425
     4264.3.15 ACCESS_GROUP_REF Class
     427
     428||CLASS||ACCESS_GROUP_REF||
     429||Purpose||Reference to access group in an access control service.||
     430||Inherit||OBJECT_REF||
     431||Functions||Signature||Meaning||
     432||Invariant||Type_validity: type.is_equal(“ACCESS_GROUP”)||
     433
     4344.3.16 PARTY_REF Class
     435
     436||CLASS||PARTY_REF||
     437||Purpose||Identifier for parties in a demographic or identity service. There are typically a number of subtypes of the PARTY class, including PERSON, ORGANISATION, etc. Abstract supertypes are allowed if the referenced object is of a type not known by the current implementation of this class (in other words, if the demographic model is changed by the addition of a new PARTY or ACTOR subtypes, valid PARTY_REFs can still be constructed to them).||
     438||Inherit||OBJECT_REF||
     439||Functions||Signature Meaning Type_validity: type.is_equal(“PERSON”) or type.is_equal(“ORGANISATION”) or type.is_equal(“GROUP”) or type.is_equal(“AGENT”)or type.is_equal(“ROLE”) or type.is_equal(“PARTY”) or type.is_equal(“ACTOR”)||
     440||Invariant||
     441
     442Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 46 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     443
     444[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     445
     446[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Identification Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     447
     4484.3.17 LOCATABLE_REF Class
     449
     450||CLASS||LOCATABLE_REF||
     451||Purpose||Reference to a LOCATABLE instance inside the top-level content structure inside a VERSION<T>; the path attribute is applied to the object that VERSION.data points to.||
     452||Inherit||OBJECT_REF||
     453||Attributes||Signature||Meaning||
     454||1..1 (redefined)||id: OBJECT_VERSION_ID||The identifier of the Version.||
     455||0..1||path: String||The path to an instance in question, as an absolute path with respect to the object found at VERSION.data. An empty path means that the object referred to by id being specified.||
     456||Functions||Signature||Meaning||
     457||1..1||as_uri: String||A URI form of the reference, created by concatenating the following: “!ehr://” + id.value + “/” + path||
     458||Invariant||Path_valid: path /= Void implies not path.is_empty||
     459
     460[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 47 of 67] Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007]
     461
     462  © 2003-2006 The openEHR Foundation    email: info@openEHR.org web: !http://www.openEHR.org
     463
     464Identification Package [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]
     465
     466Date of Issue:[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15448 08 Apr 2007] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_19440 Page 48 of 67] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}]
     467
     468[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15429 © 2003-2006 The openEHR Foundation]  email: info@openEHR.org web: !http://www.openEHR.org
     469
     470[file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15311 Support Information Model] Terminology Package Rev [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_15315 1.6.0]