Data Types Information Model

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.

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.

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:

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.

Narrative text items are used in the EHR in a number of cases, including:

While narrative text items themselves are not themselves coded, they may have code phrases associated with them, as described below under Mappings, and may be mixed within a paragraph with coded items.

Textual entities available in a terminology service are used in the health record to enable processing, from simple queries to decision support. Reasons for using terminology include the following.

A basic requirement for interoperability of text items, coded using terms (i.e. where the text is the official rubric for the code), is that both the rubric and the code (or 'code-phrase') must be recorded, to ensure the originally intended text is retained for receivers of EHR information who do not have access to the terminologies used at the origin. However, where a terminology service is available, the key can be used to unambiguously locate the string value of the term, and can also be used to find translations in other languages. (Note that these comments do not apply to mappings, which are described below).

In some terminologies, there are semantic networks of links emanating from most coded terms, which classify them or relate them to other terms. Such links provide a means for decision support to make inferences about specific things found in the record. For instance if the term "leukaemia" is found, queries to the terminology service can be made in order to deduce that the patient has both a "cancer" and a "disease of the immune system" (assuming leukaemia is classified under these more general terms in the terminology).

This specification assumes the existence of a terminology service which is responsible for interrogating actual terminologies and performing validated coordination of terms, i.e. creating combinations deemed valid by the underlying source terminology, potentially without even assigning a new code to the result. All validated coordination is carried out inside the terminology service, and any "term" made available by the service is already 'coordinated'. The difference between 'pre-coordinated' and 'post-coordinated' terms is that the former have a single code, whereas the latter have a code phrase, or expression that is interpretable by the terminology. For example, the coordination "foot, left" (a shorthand way of writing the relationship "foot has-laterality left") could be created by the terminology service from the source terms "foot", "left" and "has-laterality" from a terminology such as SNOMED. Any such coordination must be valid within the source terminology, i.e. correspond to valid relationships defined therein.

The class DV_CODED_TEXT described here captures the association of two things:

The class CODE_PHRASE.code_string records a key, in the form of arguments to some retrieval function in the terminology service interface.

The semantics attached to coordinations of terms may differ. Two categories of coordination described in the literature are 'qualification' and 'modification'. A common definition of the first is that "qualification narrows meaning" - i.e. creates a new term whose possible real world instances are within the set denoted by the original root term. Modification on the other hand changes the meaning of a root term. Various cases are described below under Meaning Modification. Both coordination types are assumed to be managed by the terminology service.

Coded terms may also be mapped to terms from other terminologies, which may be intended as equivalents, classifiers, or something in between. The section below on Mappings deals with these.

One class of modifers is exemplified by the addition of words like "risk of", "fear of", "history of" and so on. These are sometimes called mode-changing terms, since they change the "mode" of the root term from the present to the past ("history of"), a potential future ("risk of") or some other alternate reality. Terms which are modified in this way should never be matched in queries searching for the root term; for example, a query for "coronary diease" (of the patient) should not match "family history of coronary disease".

There are many terms whose meaning is changed by the context in which they are stated, such as within a certain kind of note or test result. Consider the following:

Negation is a special kind of mode change and has been a serious design challenge in the past, because modifiers like "not" or "no" only make sense when attached to some terms, and create nonsensical values or ambiguities by arbitrarily association with other terms.

Rather than provide explicit features for representing modifier terms within DV_CODED_TEXT, the general principle underlying representation of all post-coordinations other than qualifications, is that a higher-level, archetyped structure such as an ENTRY (defined in the EHR RM), is a minimal indivisible unit of information. Such higher-level entities can have internal structure, and it is possible (and desirable) to achieve the effect of combinations of terms through this structure. In the case of ENTRY, it will be via structuring of CLUSTER/ELEMENT objects. The general rule is: to obtain the full meaning of any terms found in the record, all of the node names in any ENTRY (coded or not) must be considered from the root to the relevant leaf. Conversely, the "final" meaning of any term in the record cannot be known in isolation from the rest of the terms in the structure.

Accordingly, the concept "family history of coronary disease" is represented as an ENTRY whose root is named (for example) "subject family history", and which includes further structure, which may be in greater of lesser detail; the coded term "coronary disease" would appear somewhere in this structure. The actual structure is completely defined by appropriate archetypes. Contrary to some perceptions, there is no general way to represent concepts such as "family history of coronary disease", since it will vary depending on how much detail is recorded. Where some GPs routinely record just the simplest form, others may record the details of which family members had heart problems and exactly what they were.

The same approach is used for context-dependent terms. Archetypes defining contexts such as "planned procedures" or "differential diagnosis" will use these terms as their root nodes; as a result, the meaning of any term appearing below the root can only be understood by including the root. Once again, the exact structures are completely dependent upon archetyping, and may be simple or quite sophisticated.

Negations are more complex than might first be apparent and are best handled by good archetype design. Terminologies might provide a term such as "No known allergies" which is helpful. But if someone has an allergy of some sort, the medicolegal requirement might be to record that the person has no known allergies to penicillin or another class of medication that is being prescribed. The oftenproposed approach of using a generic negation 'modifier' to deal with such issues results in further problems. Consider the use of negation with liver - "no liver", "no palpable liver", "no liver disease", "no history of liver disease", "no liver function", "no liver function tests". The meaning of negated terms may be non-sensical and difficult to interpret.

A basic principle of dealing with negatives is to realise that most naïve suggested use cases are quite ambiguous as stated. Does "no allergies" mean "no reported episode of allergy", "no allergic reactions ever", "no known allergies to medication" or something else? Does it mean that these statements are taken as given by the patient, or determined by tests? Like all medical phenomena, allergies must be described in some detail for the EHR to be of any real use. Almost inevitably, this precludes the use of negated terms. Since the actual information structure will be determined in advance by archetype designers, clinicians will almost never be in the situation of having to negate a term. However, if the need does arise, it should be dealt with by a negative or quantitative answer, i.e. a value rather than a name. For example, in any ENTRY describing current problems, the clinician may record the name/value pair "allergies: NONE". Here, "allergies" will be a DV_CODED_TEXT, and "NONE" will be either a DV_CODED_TEXT or a DV_TEXT; the two will be associated by a containing object, such as an instance of the ELEMENT class from the EHR RM. There is no explicit model of negation in openEHR.

Any text item, whether coded or not, may be classified with a coded term, for research, reporting and decision support purposes. For example, a GP working in tropical Australia may wish to write "Ross River infection", and be working with ICD9, which does not contain this term (although ICD9-CM does). He or she will use a plain text item, but will still be able to map it to an ICD9 classifier, such as the code for "arbovirus infection NOS". The same approach can be used for adding a classifying term to a coded text item. The utility of classifier terms is various: they allow decision support to make more powerful inferences; in situations where the available terminologies do not provide the classification inbuilt, and where it is known that not all users of EHR data will have terminologies available. In data terms, classification mapping can be visualised as illustrated below.

Classifying mappings are represented by adding a term to the mappings list of the original term. Each mapping is explicitly represented with an instance of TERM_MAPPING, which indicates both the term being associated with the original text item, and a value of '>' for the match attribute, which indicates that the mapping is "broader". The possible values of the match attribute are '>' (broader), '<' (narrower), and '=' (equivalent); they are taken from the ISO standards [ISO_2788]) and [ISO_5964].

Data from pathology laboratories has often been coded using a terminology local to the laboratory, due to lack of or economic unfeasibility of using existing widespread terminologies for the job. However, some laboratories also supply a nearest equivalent code from a well-known terminology such as LOINC, to enable the receiver of the data to process it in a more standard fashion. Here, "equivalence" is taken to mean a term of the same meaning but from a different vocabulary.

Another instance where equivalent terms might be supplied is to effect the translation of terms across specialist vocabularies such as nursing vocabularies when sharing EHRs across jurisdictions.

In theory, the cleanest way for senders and receivers of data coded with both a local and a more standard equivalent to deal with the mapping problem is for the originator of the local terminology to provide a complete thesaurus of translations into one or more recognised terminologies. However, in practice, laboratories using the HL7 v2.x messaging standard usually encode a primary term and equivalents with the HL7 CE data type, meaning that equivalents are included only with the term they are used with. A similar pragmatic approach to mapping equivalent terms in the EHR is likely to be used with the data types described here, and can be effected with the same mapping approach as for classification.

A further situation in which text values - this time plain text - is mapped to equivalent terms is when natural language processing is used to generate coded terms for existing free-text prose. The aim of such processing is to detect word phrases and associate them with a coded term of the same meaning, without obliterating the original text. In terms of the model described here, a CODE_PHRASE is associated with a DV_TEXT instance via the mappings attribute.

In all cases with equivalents, the value of the match attribute is '=', indicating that the mapping is a synonym.

Occasionally, there is a need to create a mapping to a term of narrower meaning than the original text item. Circumstances in which this occurs include when a clinician wants to record a syndrome such as "croup" or "influenza", but the terminology does not contain these general terms, although it does contain more specific terms, e.g. "viral laryngo-tracheitis" or "influenza type A". Clearly the clinician should be allowed to record what he/she wants (as plain text if necessary), but it should also be possible to add a mapping to the more precise term. For mappings to narrower terms, the value of the match attribute is '<'.

It has been argued in GEHR [GeHR_Aus_req] that UMLS reference terms should also be supplied with occurrences of coded terms, in the form of the UMLS concept unique identifier, or "CUI". UMLS is a way of encoding terms developed at the National Library of Medicine in the United States, and consists of a meta-thesaurus, in which terms from any extant term set (such as ICD, SNOMED, READ) can be cross-referenced. UMLS CUIs could turn out to be extremely useful for decision support and reporting.

The proper use of UMLS is that terms from particular terminologies are passed to a UMLS interface and a CUI + rubric received in response. However, the mapping approach described above could also be used to map UMLS CUIs to existing text or terms in an EHR; in this case, a DV_CODED_TEXT is constructed for each UMLS "term", where the code is the CUI and the rubric is the text rendering of the CUI (guaranteed unique in UMLS). The same approach can be used for any other thesaurus which becomes available in the future.

In cases where legacy data has to be converted to openEHR-compliant data, and only codes are available, e.g. ICD or ICPC codes, the following approach is recommended:

This expresses the reality that no text was ever recorded in the legacy system; rather a code was recorded directly in the data field. In the converted data, this code is more correctly considered a mapping.

Medicine is one domain in which symbols representing relative magnitudes are commonly used, without exact values being known. The main purpose is usually to classify patients into groups for which different decisions might be made. Thus, while approximate ranges (technically speaking - "fuzzy intervals") might be stated (such as for a urinalysis), concrete values are not of interest, only categories are. Take for example the characterisation of pain as being "mild", "medium", "severe", or the reflex response to tendon percussion as "-", "+/-", "+", "++", "+++", "++++". There may be no way to scientifically precisely quantify such values because they reflect a subjective experience of the patient or informal judgement by clinician. However, they are understood as being ordered, e.g. "++" is 'greater than' "+".

Similarly, even though the symbolic values for haemolysed blood in a urinalysis have approximate ranges stated for them, as shown below, these 'values' are not usable in the same way as true quantities.

A second requirement for ordinal values is that in many cases there is a need to associate integer values with the symbols, in order to facilitate ordered comparison, and also to enable longitudinal comparison across results of the same kind (e.g. pain, protein). Integer values may be negative, 0 and positive, typically to allow the 0 value to correspond to a neutral value in a range.

An common kind of data value in medicine is the dimensionless countable quantity, e.g. "number of doses: 2", "number of previous pregnancies: 1", "number of tablets: 3". Values of this type are always integral. Countable values need to be convertible to real numbers for statistical purposes, for example for a study of average number of pregnancies per couple.

Some countable entities such as tablets are divisible into major fractions, typically halves and occasionally quarters.

The most common kind of quantity is a measured, dimensioned quantity. Anything which is measurable (rather than countable) involves a number of data aspects, namely:

Examples of dimensioned quantities include:

A common quantitative type in science and medicine is the proportion, or ratio, which is used in situations like the following:

In general ratios have real number values, even if many examples appear to be integer ratios. Proportions with unitary denominator and % (denominator = 100) are common.

A concept superficially similar to proportions and ratios is formulations of materials, such as a solid in a liquid e.g.:

Although a single solute/single solvent formulation appears to have the same form as a ratio, the general form is for any number of substances to be mixed together, usually according to a particular procedure. Formulations are therefore not candidates for direct modelling as fine-grained quantities, but instead are constructed by archetyping a higher-level structure, each leaf element of which contains the required kind of Quantity.

Quantity ranges are ubiquitous in science and medicine, and may be defined for any kind of measured phenomenon. Examples include:

A reference range is a quantity range attached to a measured value, and is common for laboratory result values. The typical form of a reference range found in a pathology result indicates what is considered the 'normal' range for a measured value. Examples of reference ranges:

Ranges can also be quoted for drug administrations, in which case they are usually thought of as the 'therapeutic' range. For example, the anticonvulsant drug Carbamazepine has a therapeutic range of 20 - 40 μMol/L. In some cases, there are multiple ranges associated with a drug, for example, Salicylate has a therapeutic range of 1.0 - 2.5 mmol/L and a toxic range > 3.6 mmol/L

Various examples occur in which multiple ranges may be stated, including the following.

Where there are multiple ranges, the important question is: which range information is relevant to the actual data being recorded for the patient? In theory, only the range corresponding to the particular patient situation should be used, i.e. the range which applies after taking into account sex, age, smoking status, "professional athlete", organ transplanted, etc. In most cases, this is a single "normal" range, or a pair of ranges, typically "therapeutic" and "critical". However, practical factors complicate things. Firstly, data is sometimes supplied from pathology labs along with some or all of the applicable reference ranges, even though only some could possibly apply. This is particularly the case if the laboratory has no other data on the patient, and cannot evaluate which range applies. The requirement for faithfulness of recording might be extended to reference data supplied by laboratories, regardless of how irrelevant or arbitrarily chosen the reference data is, meaning that such data has to be stored in the record anyway. Secondly, there may be circumstances in which physicians want a number of reference ranges, even while knowing that only one range is applicable to the datum. Ranges above and below the relevant one might be useful to a physician wishing to determine how far out of range the datum is.

It is quite common for laboratories to include a normal range with each measured value, and/or a normal 'status', which indicates where the value lies with respect to the normal range. The latter will commonly take the form of markers like "HHH" (critically high), HH (abnormally high), H (borderline high), L, LL, LLL in HL7v2 messaging, although other schemes are undoubtedly used.

In order to make sense of the requirements in a systematic way, a proper typology for quantities is needed. The most basic characteristic of all values typically called 'quantities' is that they are ordered, meaning that the operator "<" (less-than) is defined between any two values in the domain. An ancestor class for all quantities called DV_ORDERED is accordingly defined. This type is subtyped into ordinals and true quantities, represented by the classes DV_ORDINAL and DV_QUANTIFIED respectively. DV_ORDINAL represents data values whose exact numeric values are not known, and which use symbolic renderings instead, such as "+", "++", "+++", or "mild", "medium", "severe". Each symbol can be assigned any integer value, providing a basis for computable comparison. In contrast, instances of DV_QUANTIFIED and all its subtypes have precise numeric magnitudes.

DV_QUANTIFIED itself introduces the concepts of magnitude and magnitude_status. The magnitude attribute is guaranteed to be available on any DV_QUANTIFIED, carrying the effective value, regardless of the particular subtype. The optional magnitude_status attribute can be used to provide a nonquantified indication of accuracy, and takes the following values:

If not present, meaning is "=".

Logically, an accuracy attribute should also be included in DV_QUANTIFIED, but as its modelling is different in the subtypes in a way that does not easily lend itself to a common ancestor, it is only included in the subtypes.

The DV_QUANTIFIED class has two subtypes: DV_AMOUNT and DV_ABSOLUTE_QUANTITY. The former corresponds to relative 'amounts' of something, either a physical property(such as mass) or items (e.g. cigarettes). Mathematically, the '+' and '-' operators (as well as '*' and '/') are defined in the same way as for the real numbers (or any other mathematical 'field'), with the semantics that adding two relative quantities measuring the same thing (i.e. with the same units) produces another relative quantity of the same kind; while the semantics of subtraction are that one relative quantity subtracted from another generates a third.

The second subtype of DV_QUANTIFIED, DV_ABSOLUTE_QUANTITY, models quantities whose values are absolute along a line having a defined origin. The main example of absolute quantities are the temporal concepts date, time and date/time. These are distinguished from relative quantities in that the normal addition and subtraction operations don’t apply. Instead, the semantics of such operators are based on the idea of the difference between absolute values being a relative amount. For example, two dates can be subtracted, but the result is a duration, not another date. For this reason, the operations add, subtract and diff are defined rather than '+' or '-'. Date/time types, as well as the relative concept duration, are defined in the Chapter 7.

Subtypes of DV_AMOUNT are DV_PROPORTION, DV_QUANTITY, DV_COUNT, and DV_DURATION (see date_time package). The type DV_COUNT has an integer magnitude and is used to record naturally countable things such as number of previous pregnancies, number of steps taken by a recovering stroke victim and so on. There are no units or precision in a DV_COUNT. Countable quantities can be used to create instances of DV_QUANTITY, such as during a statistical study which average tobacco consumption over a time period. Such a computation might cause the creation of DV_QUANTITY objects representing values like {magnitude = 5.85, units = '/ week'}

DV_QUANTITY is used to represent amounts of measurable things, and has a real number magnitude, precision, units and accuracy. The units attribute contains the scientific unit in a parsable form defined by the Unified Code for Units of Measure [UCUM]. A valid units string always implies a measured property, such as "force" or "pressure". The property of a Quantity can conveniently constrained in archetypes, e.g. to "pressure", which would allow any pressure unit. Unit strings can be compared to determine if they measure the same property (e.g. "bar" and "kPa" are both units corresponding to the property "pressure"), which enables the is_strictly_comparable_to function defined on DV_ORDERED to be properly specified on DV_QUANTITY.

Theoretically it might be argued that 'accuracy' should not be included in a model for quantified values, because it is an artifact of a measuring process and/or device, not of a quantity itself. For example, a weight of "82 kg ±5%" can be represented in two parts. The "82 kg" is represented as a DV_QUANTITY, while the "±5%" could be included in the protocol description of the weighing instrument, since this is where the error comes from. For practical purposes however, (in)accuracy in a measured quantity corresponds to a range of possible values. In realistic computing in health, it is quite likely that the accuracy will be required in computations on quantities, especially for statistical population queries in which measurement error must be disambiguated from true correlation.

Accuracy is therefore introduced as the abstract feature accuracy of the DV_QUANTIFIED class. It is defined concretely in the two descendants, DV_AMOUNT, where it is of type Real, and DV_ABSOLUTE_QUANTITY, where it is of a differential type defined by subtypes. A value of 0 in either case indicates 100% accuracy, i.e. no error in measurement. Where accuracy is not recorded in a quantity, it is represented by a special value. In DV_AMOUNT, a value of -1 for the accuracy attribute is used for this purpose, and the constant unknown_accuracy_value = -1 is provided within the class to give a symbolic name for the special value. In the DV_ABSOLUTE_QUANTITY class, accuracy_unknown is represented by a Void (i.e. null) value for the accuracy attribute. An abstract Boolean feature accuracy_unknown is defined in the parent class DV_QUANTIFIED to provide a logical test of accuracy being absent, and is implemented in the respective descendants by concrete functions that check for the special values.

In addition, the class DV_AMOUNT, provides a feature accuracy_is_percent: Boolean to indicate if accuracy value is to be understood as a percentage, or an absolute value.

When two compatible quantities are added or subtracted using the + or - operators (DV_AMOUNT descendants) or add and substract (DV_ABSOLUTE_QUANTITY class), accuracy behaves in the following way:

The related notion of 'uncertainty' is understood as a subjective judgement made by the clinician, indicating that he/she is not certain of a particular statement. It is not the same as accuracy: uncertainty may apply to non-quantified values, such as subjective statements, and it is not an aspect of objective measurement processes, but of human confidence. Where the uncertainty is due to subjective memory e.g. "I think my grandfather was 56 when he died", the uncertainty is simply recorded as another value, along with the main data item being recorded. Uncertainty is therefore not directly modelled in the openEHR data types, but appears instead in particular archetypes.

Ranges are modelled by the generic type DV_INTERVAL<T:DV_ORDERED> which enables a range of any of the other quantity types (except ratio) to be constructed. This allows any subtype of DV_ORDERED to occur as a range as well.

The DV_PROPORTION type is provided for representing true ratios, i.e. relative values, and consists of numerator and denominator Real values, and a magnitude function which is computed as the result of the numerator/denominator division. The type attribute is used to indicate the logical type of the proportion. Supported types include:

Lastly, the is_integral function indicates that the numerator and denominator are both integer values; this is used for fractions (the fraction and integer_fraction types above) and other commonly occurring ratios where both parts are always integer values.

Normal range for any of the quantity types (i.e. any instance of a subtype of DV_ORDERED) can be included via the attribute DV_ORDERED.normal_range, of type REFERENCE_RANGE. Other reference ranges (e.g. sub-critical, critical etc) can be included via the attribute DV_ORDERED.other_reference_ranges. The separation of normal and other reference range attributes is used because the former constitute the vast majority of ranges quoted for quantitative data.

Normal status can be included via the attribute DV_ORDERED.normal_status, which takes the form of a DV_ORDINAL, whose symbol attribute is coded according to the openEHR terminology group "normal status", and takes values "HHH" (critically high), "HH" (abnormally high), "H" (borderline high)", "N" (normal), "L" …​ "LLL".

Time can be recorded in two ways. Absolute times in the social time domain, such as dates and time of day are recorded using the types in the date_time package. Fine-grained 'time', which is a duration rather than a time, is recorded using a DV_QUANTITY with units = 's' or another temporal unit ('h', 'ms', 'ns' etc).

The basic requirement is for types which represent the following concepts:

Partial or uncertain date/times have to be supported in clinical medicine. It is common for patients to be unsure about dates and durations. Requirements for partial date/times include the following.

To satisfy the faithfulness requirement for health record recording it should always be possible to record the narrative form of the datum provided by the patient as well as the formal form.

Date/time values are somewhat special in the realm of data types in that they are expressed in their "customary" form, in which the standard structure of {value, unit} and metric relationships between orders of magnitude do not hold. The customary form is what we are used to using in the social time domain, such as births, deaths, ages, and times and durations of events which we remember. In all these cases it is expressed using the familiar year/month/date/hour/minute/second system, in which the relationships between each successive unit of time is non-metric. The customary form can be converted to a magnitude since an origin point, and many date/time libraries do this in order to implement various operations, particularly comparison.

The date/time types fall into two categories: absolute and relative. The absolute category comprises the Date, Date/time and Time concepts, each of which measure time from a known origin. Date and Date/time measure calendrical time from the date 0001-01-01, while Time measures clock time from midnight. Both Date/time and Time can include timezone information, ensuring that their instances are correctly situated on the same timeline. All absolute time types inherit from the DV_TEMPORAL type, which provides the appropriate signature for the diff() function.

The relative category contains only the Duration concept, which expresses elapsed time between two time points. The DV_DURATION class is used for expressing durations of clinical phenomena and differences between absolute times.

All four concepts are defined in the ISO 8601:2004 standard, which is accordingly used as the definitional basis of the openEHR date/time types.

The types defined in this specification support the notion of partially specified dates and times. The modelling approach used here takes into account the known needs for representing partial date/time data, while balancing that with the need to avoid incomprehensibly complex types whose generality would only apply to a tiny percent of difficult cases. Thus, the basis for modelling incomplete date/times is as follows.

Based on the above considerations, the requirements for partial types are satisfied by the semantics of ISO8601:2004 for "reduced accuracy" date/times, in which parts of a date, time or date/time can be missing from the right hand end of the string. This models the reasonable situation where e.g. day may be unknown in a date, but a date cannot have month unknown and day known.

A comment on calendars is in order. In this specification, all date/time types currently modelled are Gregorian calendar based. This is the same assumption made by by ISO 8601, and most technical computing systems today in many parts of the world. At first glance this may seem like a culturally insensitive approach, but in fact it makes sense in computational terms, for both users of the Gregorian and other calendars, e.g. Julian, Islamic, Baha’i, etc. Arguments against trying to use the date/time classes defined here to represent date/times from any calendar include the following:

For users requiring non-Gregorian dates in EHR and other health systems there are two approaches. One is to treat non-Gregorian dates as a localisation issue, to be handled inside the application and GUI evnvironment. The other is to actually add further sibling packages to the openEHR date/time package, for each new calendar or calendar group required. Conversion algorithms would most likely be needed in and out of the Gregorian types to enable interoperability of information drawn from different applications or sources. This approach may require a substantial modelling effort.

Algorithms for conversion between the Egyptian, Armenian, Khwarizmian, Persian, Ethiopian, Coptic, Republican, Macedonian, Syrian, Julian Roman, Gregorian, Islamic A, Islamic B, Baha’i and Saka calendars are described by Richards [Richards_1998] and are based on the work of D. A. Hatcher (1986).

All of the date/time classes described here are defined so as to have an attribute called value of type String, in the form of an ISO 8601:2004 string. ISO 8601 is convenient for this purpose, as it is a simple syntax, and covers not only all four variants of fully-specified date/time described here, but also the partial varieties. Using a single string attribute significantly simplifies persistence as well as mapping to XML-based formalisms, which use a mostly ISO 8601 compliant date/time representation. The ISO 8601 semantics assumed by EHR are defined in classes found in the classes ISO8601_DATE, ISO8601_TIME, ISO8601_DATE_TIME, ISO8601_DURATION, from the rm.support.assumed_types package. These classes are inherited into the corresponding classes defined below.