Basic Package

Overview

The data_types.basic package, illustrated below, contains types for the concepts of bistate, state (in a state machine) and real-world entity identifiers (see the openEHR Common IM for a discussion on identifier types).

RM data types.basic
Figure 1. rm.data_types.basic package

Requirements

Bi-state Values

One of the most basic types of data is boolean or bi-state data. The need here is for a type which both includes a boolean value, and which inherits from the type DATA_VALUE, enabling it to be used as an ELEMENT.value.

State Machine States

A type is required to represent state values of a state machine. In a simple system of data types, a simple integer would appear sufficient to perform this job. However, in an archetyped framework, a distinct type is required, so that it can be archetyped not by the constraints used for integers, but by a state machine definition instead. The type DV_STATE is provided for this purpose. An example of a state machine which models the lifecycle of a medication order is illustrated in the figure below. This definition would appear in an archetype; the values of a DV_STATE object are then restricted to the values of the states in the definition.

state machine
Figure 2. Example State Machine for Medication Orders

Real-world Entity Identification

Real world entities (RWEs) such as people, car engines, invoices, and appointments may all be assigned identifiers. Although many of these are designed to be unique within a jurisdiction or issuing space, they are often not, due to data entry errors, bad design (ids which 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. Therefore, from a strict computatoinal point of view, RWIs are not treated as reliable identifiers, but as attributes of their owning objects, in the same ways as names and addresses for example.

Examples of RWE identifiers which are intended to be unique within the space of the issuing authority or organisation include:

  • driver’s licence id

  • social security number

  • passport number

  • prescription id

The defining logical characteristic of RWE ids is that they continue to identify the entities in question, regardless of how they change in time; for example a social security number does not change when someone changes their hair colour or even their gender (both of which attributes may be recorded in the database). In general it should be the case that if two RWE ids are equal, they refer to the same RWE.

At a practical level, RWE identifiers differ from information entity (IE) identifiers in that the former are generally not assigned by the computing infrastructure that uses them - that is to say, in the production computing system, such identifiers are no different from other characteristics of the entity, such as names or addresses.

Design

The model defined here in the DV_IDENTIFIER class allows the recording of three things as part of identifying an item of interest:

  • the identifier given to the item of interest (mandatory).

  • the issuing authority of the kind of id used (e.g. it might be the federal department of health) (optional);

  • the assigner of the id to the item being identified. This is usually the organisation which created the item being identified (optional);

In addition, a type of item being identified can also be recorded, such as 'driver’s licence' or 'Medicare card'. All fields are text fields, rather than coded, as no definitive vocabularies are available. However, some useful sources of terms exists, such as HL7v2 Table 0203 for the type field. If using the latter, it is recommended to use the 'description', not the code.

Only the identifier field is mandatory to allow for use cases in which the other fields cannot be populated. However it is strongly recommended to populate the type and issuer fields where possible. In many cases the issuer and assigner have the same value, however two fields allow for the situation in which a central issuer provides blocks of identifiers (typically on some kind of form or other paperwork) to other organisations who then assign them to individuals, as is often done with prescription identifiers.

See the Support IM specification for a further discussion of RWEs and IEs, and the definition of IEs in openEHR.

Class Descriptions

Unresolved include directive in modules/data_types/pages/basic_package.adoc - include::../UML/classes/data_value.adoc[]

Unresolved include directive in modules/data_types/pages/basic_package.adoc - include::../UML/classes/dv_boolean.adoc[]

Unresolved include directive in modules/data_types/pages/basic_package.adoc - include::../UML/classes/dv_state.adoc[]

Unresolved include directive in modules/data_types/pages/basic_package.adoc - include::../UML/classes/dv_identifier.adoc[]