Data Structures Information Model

DV_QUANTITY DV_QUANTITY DV_QUANTITY

v = XX v = XX v = XX

BIOCHEMISTRY RESULT

sample = serum lipid studies

Logical Form

total cholesterol = 6.1 mmol/L HDL cholesterol = 0.9 mmol/L LDL cholesterol = 5.2 mmol/L

comment: high cardiac risk

FIGURE 6 ITEM_TREE Instance Structure

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 21 of 39 Date of Issue: 26 Sep 2006

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

Item Structure Package Data Structures Information Model Rev 1.7

Date of Issue: 26 Sep 2006 Page 22 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model Representation Package Rev 1.7

Representation Package

5.1 Overview

This package contains classes for a simple hierarchical representation of any data structure, as shown in FIGURE 7 . These classes are compatible with the CEN EN13606 classes of the same names, and instances can be losslessly generated to and from EN13606 instances structures.

LOCATABLE (rm.common.archetyped)

DATA_VALUE

(rm.data_types.basic)

coded by openEHR Terminology group “null flavour”

FIGURE 7 rm.data_structures.representation Package

5.2 Class Descriptions

5.2.1 ITEM Class

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

CLASS	ITEM (abstract)
Purpose	The abstract parent of CLUSTERand ELEMENT representation classes.
CEN	ITEM class
OMG HDTF	COAS::Observation
Synapses	Item class
GEHR	G1_HIERARCHICAL_ITEM
HL7v3	n/a
Inherit	LOCATABLE
Attributes	Signature	Meaning

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 23 of 39 Date of Issue: 26 Sep 2006

Representation Package Data Structures Information Model Rev 1.7

5.2.2 CLUSTER Class

CLASS	CLUSTER
Purpose	The grouping variant of ITEM, which may contain further instances of ITEM, in an ordered list.
CEN	(ENV 13606:2000) ClusterOCC class; (prEN 13606:2006)
OMG HDTF	COAS::CompositeObservation
Synapses	Compound class
GEHR	G1_HIERARCHICAL_GROUP
HL7v3	Act_context
Inherit	ITEM
Attributes	Signature	Meaning
	items: List<ITEM>	Ordered list of items -CLUSTER or ELEMENT objects - under this CLUSTER.
Invariants	Items_non_empty: items /= Void and then not items.empty

Date of Issue: 26 Sep 2006 Page 24 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model		Representation Package
		Rev 1.7
5.2.3	ELEMENT Class

CLASS	ELEMENT
Purpose	The leaf variant of ITEM, to which a DATA_VALUE instance is attached.
CEN	DataItem class
OMG HDTF	COAS::AtomicObservation
Synapses	Element class
GEHR	G1_HIERARCHICAL_VALUE
HL7v3	Act
Inherit	ITEM
Attributes	Signature	Meaning
0..1 (cond)	value: DATA_VALUE	data value of this leaf
0..1 (cond)	null_flavor: DV_CODED_TEXT	flavour of null value, e.g. indeterminate, not asked etc
Functions	Signature	Meaning
1..1	is_null: Boolean	True if value logically not known, e.g. if indeterminate, not asked etc.
Invariants	Is_null_valid: is_null = (value = Void) Null_flavor_indicated: is_null xor null_flavour = Void Null_flavour_valid: is_null implies terminology(Terminology_id_openehr).has_code_for_group_id (Group_id_null_flavour, null_flavor.defining_code)

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 25 of 39 Date of Issue: 26 Sep 2006

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

Representation Package Data Structures Information Model Rev 1.7

Date of Issue: 26 Sep 2006 Page 26 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model History Package Rev 1.7

History Package

6.1 Overview

The history package defines classes which formalise the concept of past, linear time, via which historical data of any structural complexity can be recorded. It supports both instantaneous and interval event samples within periodic and aperiodic series. Data recorded in interval events are tagged with a mathematical function, including ‘point-in-time’, ‘mean’, ‘delta’ and so on, as defined by the openEHR “event math function” vocabulary. It also supports the inclusion of “summary” data, i.e. a textual or image item which summarises in some way the entire history.

Regardless of whether the actual data consist of a single sample or many, they are represented in the same way: as a history of events, i.e. as a time series, allowing all software to access data in a uniform way, whether it is a single measurement of weight, a long series of three- or four-dimensional images, or even a series of encapsulated multimedia items.

The model defines the constrained generic (otherwise known as ‘template’ or ‘parameterised’) types HISTORY<T>, EVENT<T>, POINT_EVENT<T>, and INTERVAL_EVENT<T> where the type parameter is constrained to the ITEM_STRUCTURE type, and defines the type of the data recorded in an instance of HISTORY. The effect is that repeated instances of spatially complex data can recur in time, corresponding to the way data are actually measured. An aperiodic series of POINT_EVENT instances would typically be used to represent manual measurements repeated in time. Periodic histories of INTERVAL_EVENT instances would typically be used to represent vital signs monitor output (which is usually delivered in averaged form potentially with additional minimum and maximum values).

As with all other parts of the openEHR reference model, the History package is designed for archetyping; archetypes define the domain semantics of HISTORY instances. The history package is shown in FIGURE 8.

6.1.1 Semantics

Basic Semantics

The intention of the History model is to represent time-based data for which every sample in the series is a measurement of the same phenomenon (e.g. patient heartrate) and is obtained using the same measurement method (e.g. pulse oximeter). Samples taken in this way can be reliably treated as representing changes in a phenomenon over time, and accordingly can be safely used for time-based computation, such as graphing, statistical analysis and so on. A History can contain any mixture of POINT_EVENT and INTERVAL_EVENT instances. Clearly it is impossible for the model to guarantee completely correct usage on its own, however there two major safeguards.

Firstly, the use of generic types forces the type of the data in each Event to be the same. A History of type HISTORY<ITEM_LIST> therefore constrains the type of the data at each Event (EVENT.item) to be of type ITEM_LIST and nothing else.

Secondly, the use of archetyping (typically within openEHR Observation archetypes) ensures the actual structure of the ITEM_STRUCTURE subtype is defined in the same way for every sample - e.g. a two-item list representing systolic and diastolic blood pressure.

Timing

An instance of the HISTORY class contains the origin: DV_DATE_TIME attribute, indicating what is considered the ‘0-point’ of the time series, and a series of instances of the EVENT subtype, each containing a time: DV_DATE_TIME attribute representing the absolute time of the event. The relative off-

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 27 of 39 Date of Issue: 26 Sep 2006

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

History Package Data Structures Information Model Rev 1.7

LOCATABLE (rm.common.archetyped)

FIGURE 8 rm.data_structures.history Package

set of any Event is computed as the difference between the EVENT.time and HISTORY.origin by the EVENT.offset function. For Interval events (i.e. instances of INTERVAL_EVENT), the time attribute always refers to the end time of the event, since this is the time at which the data (e.g. average) are true.

The origin time of a History does not have to be the time of the first sample - it might be the time of an event such as child-birth with respect to which the samples are recorded, e.g. Apgar¹ scores at 1 and 3 minute offsets. Periodicity and aperiodicity are expressed via the is_periodic and period attributes. For a periodic time-series, period is set to the period duration value and is_periodic returns True. The total duration of the History is given by the HISTORY.duration function. FIGURE 9 illus trates a number of variations in History periodicity and Event type.

Point Events

The simplest kind of Event in a History is a “point” event, expressed by instances of the class POINT_EVENT, representing an instantaneous value. A History instance many be composed solely of Point events, as would be the case with a number of blood pressure values measured over time as the patient changes position. An Apgar result is a typical example of aperiodic point data, typically con

1. A 0-10 score indicating the health of a newborn based on breathing, heartrate, colour, muscle-tone and reflexes

Date of Issue: 26 Sep 2006 Page 28 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model History Package Rev 1.7

periodic, point events

periodic, interval events

aperiodic, point events

aperiodic, mixed point and interval events

FIGURE 9 Variation in History periodicity and Event width

sisting of 2 or 3 events, each containing 5 values and a 6th value repersenting the Apgar score for that time point. Point data may also be available from monitoring devices. For fine-granularity (e.g. 1 second) data, the number of samples may be too voluminous for the health record, and more efficient recording in the form of summary Interval events (see below) might be desired. FIGURE 10 illus trates the structure of a HISTORY containing POINT_EVENTs.

blood pressure

t

FIGURE 10 Structure of HISTORY<T> of POINT_EVENTs

Interval Events

Instances of the INTERVAL_EVENT class are used to express values corresponding to an interval in time. The INTERVAL_EVENT.width attribute defines the duration of the interval; and the inherited time value corresponds to the trailing edge of the event.

The meaning of an Interval event in this model is that the values effectively summarise actual instantaneous values of a datum that have occurred during the period of the event interval. The mathematical meaning of the data of any particular interval event is given by the math_function attribute. This is coded by the openEHR Terminology group “event math function”, and takes values such as “minimum”, “maximum”, “average”, “delta” and so on. The particular math functions used in each Interval event in a History may vary throughout the History; for example, one 4-hour Interval event might contain data representing average values, while a following event might contain data representing

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 29 of 39 Date of Issue: 26 Sep 2006

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

History Package Data Structures Information Model Rev 1.7

maximum values. Such data can be conveniently used for generating sophisticated graphs of the underlying datum over time. FIGURE 11 illustrates a History containing 2 pairs of 4-hour blood pres sure Interval events, with each pair containing maximum and mean blood pressure value structures for +4h and +8h timepoints (each of which consist of a systolic and diastolic value).

Interval events can overlap other interval or point events within the same History. A common situation where this occurs is with measurement of different periods of vital signs, such as 4-hourly blood pressure events, overlapped by a 24-hour event which contains the values over a period of 6 x 4 hour periods. In general a long Interval event can overlap any combination of Point or Interval events, as shown in FIGURE 12 .

Change Data

One subcategory of interval data that deserves mention is change data. There are three event math function terms used for indicating changes in data values as follows:

• “change”: this means that the value recorded is the difference between the value now and the value some time previously. It can be positive or negative;

Date of Issue: 26 Sep 2006 Page 30 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model History Package Rev 1.7

• “increase”: the value recorded for the change is positive. The name (i.e. ELEMENT.name) chosen for the item in an archetype carries the semantic of positivity e.g. "increase of ....; rise of....; ....gain" etc;
• “decrease”: the value recorded for the change is positive. But the name chosen for the item carries the semantic of negativity e.g. "decrease of ....; fall of ....; .... loss".

The following examples show how the data and these math functions are coordinated.

• weight last week was 76 kg. Wait this week = 74 kg. Possible instances:
• weight last week was 80 kg. Weight this week = 83 kg. Possible instances:

Item Name in Archetype	Value stored	Type	Math Function
“weight change”	+ 2kg	DV_QUANTITY	“change”
“weight loss”	(+)2kg	DV_QUANTITY	“decrease”
“weight loss”	True	Boolean	“decrease”

Item Name in Archetype	Value stored	Type	Math Function
“weight change”	(+)3kg	DV_QUANTITY	“change”
“weight increase”	(+)3kg	DV_QUANTITY	“increase”
“weight gain”	True	Boolean	“decrease”

The use of these math function indicators allows the correct representation of change values, no matter how they were captured, in a computable form.

Summary Event Data

A relatively common situation particularly in laboratory testing is the existence of a “summarising” event which accompanies more detailed historical data. Examples where this arises include:¹

• a series of exams with a single radiologist report for all of them (the report might include one or more key images);
• graphical summary of a dynamic challenge test such as Glucose tolerance test;
• some comment about the pattern of values on a set of observed values in series.

Such data are accommodated within the model via the optional HISTORY.summary attribute, which is itself a structure, archetypable separately from the structure of the main data. In the first example above, the summary data might consist of an ITEM_SINGLE object containing a textual report; in the second, an ITEM_SINGLE object containing a image within a DV_MULTIMEDIA instance.

Efficient Representation of Fine-grained Device Data

A useful practical consequence of the of Interval Events is that it allows long periods of relatively stable data to be represented with a single Interval event, while interesting perturbations will be repre sented with a number of fine-grained Interval or Point Events. In the example in FIGURE 13 5 Event instances are used represent 4 hours of data consisting to 14,400 x 1 second samples from a blood pressure monitor. The optional INTERVAL_EVENT.sample_count attribute can be used to record the number of original samples summarised in the event. In the illustration, the math_function is shown as mean; clearly in the first long period, the monitored datum was not absolutely flat. The implication

1. Examples provided by G Grieve of Kestral Computing, Australia

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 31 of 39 Date of Issue: 26 Sep 2006

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

History Package Data Structures Information Model Rev 1.7

is that the recording software was configured to regard variations in a small band (e.g. 5mm Hg) as insignificant, and only to create new Event objects when the underlying values moved outside the band. Another approach woould have been to create two Interval Event objects for each long period, one giving minimum value, the other maxium value, still based on the principle of generating one such pair for periods when the underlying data remained within specified limits. Regardless of the details, this general approach provides a way to include hours of fine-grained data from devices like vital signs monitors in very little space; the data simply need to be transfomed into equivalent openEHR History form first.

5 x INTERVAL_EVENT instances

State

A feature particular to a model of recording historical data for scientific and clinical use is the ability to record ‘state’. In openEHR, ‘state’ is understood as information pertinent to the correct interpretation of the primary data. A simple example is where the primary datum is heartrate; useful state data would be the level of exertion of the subject (resting, after 3 minutes cycling etc). In clinical recording situations, the state data is often crucial to the safe use of the primary data, since the latter might be normal or abnormal depending on the patient state. In openEHR there are two ways of recording state. One is via the use of a separate HISTORY structure within the OBSERVATION class (see ehr.composition.content.entry package). The other is via the use of the state attribute of type ITEM_STRUCTURE defined in the class EVENT itself. Experience with openEHR archetypes and systems has shown that the latter method corresponds to the most common clinical need, which is to be able to record the state at the time of the event (the other method allows for the recording of independent state events). A simple example is the recording of 3 glucose levels during a glucose tolerance test. The state information for each event is, respectively (in a typical test):

• 0-minute sample: “post 8-hour fast”;
• 1-hour sample: “post 75g oral glucose challenge”;
• 2-hour sample: “post 75g oral glucose challenge”.

Date of Issue: 26 Sep 2006 Page 32 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model	History Package
	Rev 1.7
The History structure for this example is illustrated in FIGURE 14.

x 9.0 mmol/l

blood

x 6.0 mmol/l

glucose x 4.5 mmol/l

t

0 min 1 hr 2 hr

Snomed::10000014 Snomed::10000003 Snomed::10000003 “post 8hr fast” “post 75mg glucose “post 75mg glucose challenge” challenge”

FIGURE 14 State in HISTORY

6.2 Class Descriptions

6.2.1 HISTORY<T: ITEM_STRUCTURE> Class

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

CLASS	HISTORY<T: ITEM_STRUCTURE>
Purpose	Root object of a linear history, i.e. time series structure. For a periodic series of events, period will be set, and the time of each Event in the History must correspond; i.e. the EVENT.offset must be a multiple of period for each Event. Missing events in a period History are however allowed.
CEN	Time was encoded as part of the Item structure.
GEHR	Time was encoded as part of the G1_HIERARCHICAL_PROPOSITION structure.
HL7v3	The data type HIST<T>is equivalent in intention to HISTORY<T>for histories of primitive values; for histories of complex data, Act/Act-relationship structures have to be used.
Inherit	DATA_STRUCTURE
Attributes	Signature	Meaning
1..1	origin: DV_DATE_TIME	Time origin of this event history. The first event is not necessarily at the origin point.
0..1	events: List <EVENT<T>>	The events in the series.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 33 of 39 Date of Issue: 26 Sep 2006

History Package Data Structures Information Model Rev 1.7

CLASS	HISTORY<T: ITEM_STRUCTURE>
0..1	period: DV_DURATION	Period between samples in this segment if periodic.
0..1	duration: DV_DURATION	Duration of the entire History; either corresponds to the duration of all the events, and/or the duration represented by the summary, if it exists.
0..1	summary: ITEM_STRUCTURE	Optional summary data expressing e.g. text or image which summarises entire History.
Functions	Signature	Meaning
1..1	is_periodic: Boolean	Indicates whether history is periodic.
	as_hierarchy: CLUSTER	Generate a CEN EN13606-compatible hierarchy of the physical representation.
Invariants	origin_exists: origin /= Void events_exists: (events /= Void and then not events.is_empty) or summary /= Void periodic_validity: is_periodic xor period = Void period_consistency: is_periodic implies events.for_all (e: EVENT | e.offset.to_seconds.mod(period.to_seconds) = 0)

6.2.2 EVENT <T: ITEM_STRUCTURE> Class

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

CLASS	EVENT <T: ITEM_STRUCTURE> (abstract)
Purpose	Defines the abstract notion of a single event in a series. This class is generic, allowing types to be generated which are locked to particular spatial types, such as EVENT<ITEM_LIST>. Subtypes express point or intveral data.
HL7v3	The data type HistoryItem HXIT<T> is close to EVENT<T> in its intent.
Inherit	LOCATABLE
Attributes	Signature	Meaning
1..1	time: DV_DATE_TIME	Time of this event. If the width is non-zero, it is the time point of the trailing edge of the event.
1..1	data: T	The data of this event.
0..1	state: ITEM_STRUCTURE	Optional state data for this event.
Functions	Signature	Meaning

Date of Issue: 26 Sep 2006 Page 34 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Data Structures Information Model History Package Rev 1.7

CLASS	EVENT <T: ITEM_STRUCTURE> (abstract)
(redefined)	parent: HISTORY<T>	Redefinition of LOCATABLE.parent to be of type HISTORY.
1..1	offset: DV_DURATION	Offset of this event from origin, computed as time.diff(parent.origin)
Invariants	Time_exists: time /= Void Data_exists: data /= Void Offset_validity: offset /= Void and then offset = time.diff(parent.origin)

6.2.3 POINT_EVENT <T: ITEM_STRUCTURE> Class

CLASS	POINT_EVENT <T: ITEM_STRUCTURE>
Purpose	Defines a single point event in a series.
Inherit	EVENT
Attributes	Signature	Meaning
Invariants

6.2.4 INTERVAL_EVENT <T: ITEM_STRUCTURE> Class

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

CLASS	INTERVAL_EVENT <T: ITEM_STRUCTURE>
Purpose	Defines a single interval event in a series.
Inherit	EVENT
Attributes	Signature	Meaning
1..1	width: DV_DURATION	Length of the interval during which the state was true. Void if an instantaneous event.
1..1	math_function: DV_CODED_TEXT	Mathematical function of the data of this event, e.g. “maximum”, “mean” etc. Coded using openEHR Terminology group “event math function”.
0..1	sample_count: Integer	Optional count of original samples to which this event corresponds.
Functions	Signature	Meaning
1..1	interval_start_time: DV_DATE_TIME	Start time of the interval of this event.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 35 of 39 Date of Issue: 26 Sep 2006

History Package Data Structures Information Model Rev 1.7

Width_valid: width /= Void Math_function_validity: terminology(Terminology_id_openehr). has_code_for_group_id(Group_id_event_math_function, math_function.defining_code) Interval_start_time_valid: interval_start_time /= Void and interval_start_time = time - width

6.3 History Instance Structures

6.3.1 Single Sample

FIGURE 15 illustrates a single weight measurement. The Event objects contain the timing information, which in this case is simply the time of measurement (the origin).

ITEM_SINGLE

itemdata items

m = “weight” n = “weight”

6.3.2 5-minute Blood Pressure Averages

FIGURE 16 illustrates two Interval events representing 5 minute blood pressure averages, the first at 5 minutes’ offset from an initial event and lasting 5 minutes, the second 5 minutes later.

Date of Issue: 26 Sep 2006 Page 36 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model References Rev 1.7

A References

A.1 General

1 Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. See http://www.deepthought.com.au/it/archetypes.html .

2 Beale T et al. Design Principles for the EHR. See http://www.deepthought.com.au/openEHR .

3 Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. International Standards Organisation, Australia; Feb 2002; ISO TC 215/SC N; ISO/WD 18308.

A.2 European Projects

4 Dixon R., Grubb P.A., Lloyd D., and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 200159pp Available from http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v1_3.PDF .

5 Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 3.5: "Final Recommendations to CEN for future work". Oct 2000. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR SupA/documents.htm .

6 Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 2.4 "Guidelines on Interpretation and implementation of CEN EHCRA". Oct 2000. Available at ht tp://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm .

7 Ingram D. The Good European Health Record Project. Laires, Laderia Christensen, Eds. Health in the New Communications Age. Amsterdam: IOS Press; 1995; pp. 66-74.

8 Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995

A.3 CEN

9 ENV 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. CEN/ TC 251 Health Informatics Technical Committee.

10 ENV 13606-4 -Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. CEN/ TC 251 Health Informatics Technical Committee.

A.4 OMG

11 CORBAmed document: Person Identification Service. (March 1999). (Authors?)

12 CORBAmed document: Lexicon Query Service. (March 1999). (Authors?)

A.5 Software Engineering

13 Meyer B. Object-oriented Software Construction, 2nd Ed.

Prentice Hall 1997

14 Fowler M. Analysis Patterns: Reusable Object Models. Addison Wesley 1997

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 37 of 39 Date of Issue: 26 Sep 2006

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

References Data Structures Information Model Rev 1.7

15 Fowler M, Scott K. UML Distilled (2nd Ed.). Addison Wesley Longman 2000

A.6 Resources

16 IANA - http://www.iana.org/ .

Date of Issue: 26 Sep 2006 Page 38 of 39 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Data Structures Information Model

Rev 1.7

END OF DOCUMENT

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 39 of 39 Date of Issue: 26 Sep 2006

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