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 FIGURE 3 . 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 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.

Date of Issue: 12 Apr 2007 Page 18 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Basic Package Rev 2.1.0

start

FIGURE 3 Example State Machine for Medication Orders

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.

5.1.1.1 Narrative Text

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

• values of coded attributes in the reference model;
• recording of subjective or imprecise patient responses, particularly quantities or dates not deemed sufficiently precise to be represented using structured quantitative or date/time date types;
• recording of narrative statements, e.g. visual observations;
• recording of tracts of prose, e.g. overall findings and conclusions, prognoses;
• recording of values that would normally be coded, but for which no code and/or no terminology service is available.

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

5.1.1.2 Terminological Entities

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.

• To guarantee interoperability of meaning. For instance, if the term “cold” is recorded in plain text, it could be interpreted as “feeling cold”, “C.O.L.D” (chronic obstructive lung disease), “rhinorrhoea”, “coryza” or “U.R.T.I. (upper respiriatory tract infection), among others. If, however, it is coded from a terminology such as ICD10 or SNOMED-CT, any party reading the data (including software) knows the intention, since the meaning of the code in the terminology is unambiguous.
• To standardise textual renderings of terms and avoid informal shorthand. For example, practitioners wanting to write “systolic blood pressure” write things like “systolic BP”, “systolic bp”, “sys. BP.” and so on; use of coded terms ensures that such abbreviations are either avoided, or associated with an unambiguous meaning.
• For unambiguous naming of problems, medications or diagnoses for support of knowledge-based tools such as prescribing packages and other decision support applications.
• For standardised names of things in the record e.g. a heading of “Physical examination” or an entry such as “Differential diagnosis”.
• For finite sets of values (‘value sets’), e.g. Blood Group = ‘A|B|AB|O’.
• For classifying other data for the purpose of statistical studies, e.g. by putting ICD disease group classifiers on actual disease names entered in health records.

Date of Issue: 12 Apr 2007 Page 24 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Text Package Rev 2.1.0

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_TEXTdescribed here captures the association of two things:

• the code phrase of a code phrase provided by the terminology service, recorded in the defining_code attribute.
• the text rubric of the code phrase, recorded in the value attribute (inherited from DV_TEXT);

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.

5.1.4.1 Mode-changing Terms

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

5.1.4.2 Context Sensitivity

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:

• a blood sugar level after a 75gm oral loading has a different meaning than a fasting blood sugar;

Date of Issue: 12 Apr 2007 Page 26 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Text Package Rev 2.1.0

• a systolic blood pressure in the pulmonary artery has a different meaning than a systemic arterial blood pressure;
• “total hip replacement” in the context of a “planned procedure";
• “meningitis” in the context of a “differential diagnosis”.

5.1.4.3 Negation

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.

5.1.4.4 Representation of Meaning-Modifying 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 often-proposed 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 arche

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 27 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Text Package Data Types Information Model Rev 2.1.0

type 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_TEXTor 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.

5.1.5.1 Classification (Broader Terms)

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 in FIGURE 6.

visible text (“what the clinician said”)

FIGURE 6 Plain Text and Coded Text with Classifier(s)

Date of Issue: 12 Apr 2007 Page 28 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Text Package Rev 2.1.0

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 2788 (“Guide to Establishment and development of monolingual thesauri”) and 5964 (“Guide to Establishment and development of multilingual thesauri”).

5.1.5.2 Equivalent / Synonymous Terms

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 this case, an instance of DV_CODED_TEXT is associated with an instance of DV_TEXT via the mappings attribute.

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

5.1.5.3 More Specific Mappings (Narrower Terms)

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 ‘<’.

5.1.5.4 The Unified Medical Language System (UMLS)

It has been argued in GEHR [14] that UMLS reference terms should also be supplied with occur rences 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.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 29 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Text Package Data Types Information Model Rev 2.1.0

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.

5.1.5.5 Legacy Mapping Scenarios

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:

• create a new DV_TEXT whose value is “(not available)”
• add a mapping to the DV_TEXT, with: -purpose = “legacy conversion” -match = “=” -target = CODE_PHRASE object whose code_string and terminology_id are set to

correspond to the available code in the legacy data.

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.

Ordinal Values

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.

• “neg”, “trace” (10 cells/µl)
• “small” (<25 cells/µl)
• “moderate” (<80 cells/µl)
• “large” (>200 cells/µl)

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.

[Note: an argument sometimes put forward for recording all ordinals in a more precise way is that comparisons might want to be made between the values quoted by two laboratories for the same symbol (e.g. “moderate”). There are a number of counter-arguments. Firstly, such comparisons are a poor attempt at normalisation, an activity which is the business of pathologists, not EHR users. Secondly, the symbolic values are often arrived at by the tester making a judgement of colour on a strip, which while an adequate (and cost-effective) approach for classifying, is not a valid means of quantifying a value. Lastly, in most cases, if a quantified point value or range is desired, or available, then it will be used - meaning that the appropriate quantitative data type can be used, rather than an the ordinal type.]

Countable Things

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.

Dimensioned Quantities

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:

• a magnitude whose value is a real number;
• the physical property being measured, with the appropriate units;

Date of Issue: 12 Apr 2007 Page 38 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Quantity Package Rev 2.1.0

• a concept of precision, i.e. to what number of decimal places the value is recorded;
• a concept of accuracy, i.e. the known or assumed error in the measurement due to instrumentation or human judgement.

Examples of dimensioned quantities include:

• systolic BP: 110 mmHg
• height: 178 cm
• rate of asthma attacks: 7 /week
• weight loss: 2.5 kg

Ratios and Proportions

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

• 1:128 (a titer);
• Na:K concentration ratio (unitary denominator);
• albumin:creatinine ratio;
• % e.g. red cell distribution width (RDW) which is the width of a distribution of RBC widths.

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.

Formulations

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

• 250 mg / 500 ml (solute/solvent)

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

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

• healthy weight range, e.g. 48kg - 60kg
• normal range for urinalysis in pregnancy - protein, e.g. “nil” - “trace”

Reference Ranges

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:

• normal range for serum Na is 135 - 145 mmol/L.
• desirable total cholesterol: < 5.5 mmol/L (strictly this probably should be 2.0 - 5.5 mmol/L, but is not usually quoted this way as low cholesterol is not considered a problem.)

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

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 39 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Quantity Package Data Types Information Model Rev 2.1.0

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.

• The administration recomendations for drugs which depend on the particular patient state. For example, the therapeutic range of Cyclosporin (an immunosuppresant) is a function of time post-transplant for the affected organ, e.g. kidney: < 6 months: 250 - 350 µg/L, > 6 months: 100 - 200 µg/L.
• Normal ranges for blood IgG, IgA, IgM which vary significantly with the age in months from birth.
• Progesterone and pituitary hormones have ranges which are different for different phases of the menstrual cycle and for menopause. This may result in 4 or 5 ranges given for one result. Only one will apply to any particular patient - but the exact phase of the cycle may be unknown - so the ranges may need to be associated with the value with no 'normal' range.

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.

Normal Range and Status in Laboratory data

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.

Basic Semantics

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.

Date of Issue: 12 Apr 2007 Page 40 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Quantity Package Rev 2.1.0

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 non-quantified indication of accuracy, and takes the following values:

• “=” : magnitude is a point value
• “<“ : value is < magnitude
• “>” : value is > magnitude
• “<=” : value is <= magnitude
• “>=” : value is >= magnitude
• “~” : value is approximately magnitude

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 Date Time Package on page 55.

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) [8] . 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.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 41 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Quantity Package Data Types Information Model Rev 2.1.0

It is important to note that while these semantics will allow comparison of e.g. two pressures recorded in mbar and mmHg, or even two accelerations whose units are “m.s^-2” and “m/s^2”, they provide no guarantee that this is a sensible thing to do in terms of domain semantics: comparing a blood pressure to an atmospheric pressure for example may or may not make any sense. It is not within the scope of the quantity package to express such semantics: this is up to application software which uses Quantities found in specific places in the data.

Accuracy and Uncertainty

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%” may 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 the quantity, especially for statistical population queries in which measurement error must be disambiguated from true correlation. Accuracy is therefore included as an attribute of DV_AMOUNT, where it is of type Real (if no accuracy recorded its value is 0), and DV_ABSOLUTE_QUANTITY, where it is of a differential type defined by subtypes (no accuracy recorded corresponds to a Void accuracy attribute).

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.

Quantity Ranges

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.

Proportions

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:

• percent: denominator is 100; usual presentation is “numerator %”
• unitary: denominator is 1; usual presentation is “numerator”
• fraction: numerator and denominator are both integer values; usual presentation is n/d, e.g. such as ½ or ¾, 1/2, 3/4 etc;
• integer_fraction: numerator and denominator are both integer values; usual presentation is n/d; if numerator > denominator, display as “a b/c”, i.e. the integer part followed by the remaining fraction part, e.g. 1½; this is the most likely form for expressing a number of tablets;
• ratio: numerator and denominator can take any value; usual presentation is “numerator:denominator”

Date of Issue: 12 Apr 2007 Page 42 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Quantity Package Rev 2.1.0

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 and Reference Ranges

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. subcritical, 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 atttribute 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”.

Recording Time

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

Parse Specification

units ::= ‘/’ exp_units | units ‘.’ exp_units | units ‘/’ exp_units | exp_units

Date of Issue: 12 Apr 2007 Page 50 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Quantity Package Rev 2.1.0

exp_units ::= unit_group exponent | unit_group

unit_group ::= PREFIX annot_unit | annot_unit | ‘(’ exp_units ‘)’ | factor

annot_unit ::= unit_name | unit_name ‘{’ ANNOTATION ‘}’ | ‘{’ ANNOTATION ‘}’

factor ::= Integer

exponent ::= SIGN Integer | Integer

Lexical Specification

PREFIX ::= ‘Y’ |‘Z’ | ‘E’ | ‘P’ | ‘T’ | ‘G’ | ‘M’ | ‘k’ | ‘h’ | ‘da’

| ‘d’ | ‘c’ | ‘m’ | ‘µ’ | ‘n’ | ‘p’ | ‘f’ | ‘a’ | ‘z’ | ‘y’ UNIT_NAME ::= [a-zA-Z_%]+ ; from unit tables ANNOTATION ::= [a-zA-Z’.]+ ; from unit tables SUFFIX ::= [a-zA-Z0-9’_]+ ; from unit tables

SIGN ::= ‘+’ | ‘-’ Integer ::= [0-9]+

This proposal is comprehensive, covering all useful unit systems, including SI, various imperial, customary mesaures, and some obscure measures, as well as clinically specific additions. Metric prefixes, meaning-changing textual suffixes (e.g. “[Hg]” in “mm[Hg]”) and non-meaning-changing annotations (e.g. “kg {total}”) are recognised. With this syntax, units can be simply expressed in strings such as:

“kg/m^2”, “m.s^-1”, “km/h”, “mm[Hg]”

and so on.

6.2.9 DV_COUNT Class

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 51 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Quantity Package Data Types Information Model Rev 2.1.0

6.2.10 DV_PROPORTION Class

Date of Issue: 12 Apr 2007 Page 52 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Data Types Information Model Quantity Package Rev 2.1.0

6.2.11 PROPORTION_KIND Class

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 53 of 91 Date of Issue: 12 Apr 2007

Quantity Package Data Types Information Model Rev 2.1.0

6.2.12 DV_ABSOLUTE_QUANTITY Class

Date of Issue: 12 Apr 2007 Page 54 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Date Time Package Rev 2.1.0

Standard Date/Times

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

• Date: a type which records year, month and day in month. Examples include date of birth, date of onset of a problem
• Time: a type which records hour, minute, second, and timezone. Examples include time of meal, time of day when a problem recurs. Timezone is required in a shared EHR repository so that times of clinical events which occurred in different timezones are comparable; this includes specialised pathology tests which might be done in another country.
• Date_time: a type which records year, month, day, hour, minute, second, and timezone. Examples include date & time of death, timestamp of any observation. Timezone required for the same reason as in Time.
• Duration: a type which records duration of an event or (in)activity, as days, hours, minutes, and seconds.

Partial Date/Times

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.

• For dates, one of the following rules applies to any instance:

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 55 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Date Time Package Data Types Information Model Rev 2.1.0

- only the year is known

- only the year and month are known

If not even the year is known, then the date is obviously extremely approximate and it would

probably be unsafe to represent it computationally. However, if computatable representation

was needed in this case, a date interval can be used. A pedantic example which breaks these

rules is someone who claims to be born on “a Monday at the start of May in 1934” (i.e. day

but not date unknown). Either the clinician determines what date the first Monday in May

1934 actually was and record that (assuming the patient’s way of accurately remembering

just happens to be via day rather than date), or else records a partial date of the form “May

1934” (in ISO 8601 form, “1934-05”) if they determine that the patient really is unsure.

• Sometimes incomplete times are recorded, which follow the same rule that either the hours or both the hours and minutes are present. Examples: -recordings by instruments which only generate hh:mm values (i.e. no seconds); -recordings by patients who report approximate times of events;
• - recordings by clinicians who use approximate times in administrations, e.g. “take insulin at 8am” really means something like 8am +/- 30 mins.
• Imprecise durations such as “2 - 3 hrs” need to be recordable in a computable form.

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.

General Approach

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.

Partial Date/Times

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

Date of Issue: 12 Apr 2007 Page 56 of 91 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Data Types Information Model Date Time Package Rev 2.1.0

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.

• The modelling problem relates only to date/time quantities that need to be computable. For extremely imprecise date/times, if the clinician feels the need, she can record it as narrative text.
• For imprecise durations, an interval should be used, i.e. DV_INTERVAL<DV_DURATION>. In this way durations like “2 - 3 hrs” can be represented, and still be computable.

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.

Calendars

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:

• Almost all dates on computer systems, including in regions such as the Indian sub-continent, Turkey and the middle east, where alternate calendars are in use, are in the Gregorian system. This is likely to be the case for some time, and may always be the case, regardless of the continued use of other calendars for religious or other purposes (outside of health);
• If a calendar indicator were used in date quantities, all software, to be correct, would have to check the value to verify that it is in the expected calendar system, and to do something special if it is not - an added cost which is a possible source of bugs and which would rarely be used. The reality is that most software produced in the western world, India etc (possibly excepting open source software) would automatically assume the Gregorian calendar, and would be in error if ever it did receive EHR data containing dates from alternate calendars.
• If/when other calendars are used in EHR or related systems, the users of those calendars will be aware of it, and include the appropriate conversion logic between Gregorian dates and their own, limiting the extra software work and quality issues to those users who actually need alternate calendars. If EHRs from such places are sent to a health care facility where Gregorian is the default, nothing special is needed to ensure that those records will contain dates comprehensible to the receiver.
• The detailed model of date/times in some other calendars is not the same as in the Gregorian calendar, so they would require different classes anyway - the classes defined here would not necessarily function correctly simply by adding a calendar field.

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.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 57 of 91 Date of Issue: 12 Apr 2007

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Date Time Package Data Types Information Model Rev 2.1.0

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 [7] and are based on the work of D. A. Hatcher (1986).

Representation

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.

calendar_alignment: String calendar_alignment: String period: DV_DURATION

event_alignment: String event_alignment: String

institution_specified: Boolean institution_specified: Boolean

FIGURE 10 rm.data_types.time_specification Package