wiki:Support Information Model 3 Assumed Types

TOC PREV NEXT

3 Assumed Types

3.1 概要

3.1 Overview

この節では、すべてのopenEHRモデルで想定される型(assumed type)について記述している。ここで選択された型の集合は以下に示される様々な公開された資料にある共通の集合に基づいている。

  • ISO 11404 (2003年版)汎用データ型
  • ISO 8601 (2004) 日付(date/time)に関する仕様
  • OMG IDL, W3C XMLスキーマを含めた、広く知られた相互可用性に関する形式
  • Java, C#, C++やEffelを含めた、広く知られたオブジェクト指向プログラミング言語

This section describes types assumed by all openEHR models. The set of types chosen here is based on a common set from various published sources, including:

  • ISO 11404 (2003 revision) general purpose data types;
  • ISO 8601 (2004) date/time specification;
  • Well-known interoperability formalisms, including OMG IDL, W3C XML-schema;
  • Well-known object-oriented programming languages, including Java, C#, C++ and Eiffel.

openEHRには二つの意図がある。第1には、モデルをベースとしたopenEHRのソフトウェアを保証するために、既存の実装技術を使ってできるだけ簡単に構築することである。第2には、便利に指定できるopenEHRモデルとして有効であるようにすると同時に、実装形式でみられる型について最小限想定しておくことである。ISO 11404 (2003)標準には実装技術のために「汎用データ型(GPD; General Purpose Datatypes1)」の基本的セマンティクスが提示されており、本文書では型について想定されることについて記述するための基準となる基礎として利用している。本文書で記述される演算(operation)やプロパティ(property)は、ISO 11404で使われているものと互換性を持つが、11404がオブジェクト指向の関数を持たないためまったく同じではない。たとえば、概念的関数 has(x:T) (集合の中に値が存在するかどうか試す)は以下で Set<T>型で定義されているが、ISO 11404 のSet型にはなく、その代わりに IsIn(x: T; s: Set<T>)関数が定義されている。しかしながら、オブジェクト指向形式では、集合型で !IsIn関数が定義されていると通常は「そのsubsetである」ことを意味する。開発者のために明確な正確性を期するためにオブジェクト指向形式の関数やプロパティを本文書では使用している。

The intention in openEHR is twofold. Firstly, to ensure that openEHR software based on the models integrates as easily as possible with existing implementation technologies, and secondly, to make the minimum possible assumptions about types found in implementation formalisms, while making sufficient assumptions to both enable openEHR models to be conveniently specified. The ISO 11404 (2003) standard contains basic semantics of “general purpose data types” (GPDs) for information technology, and is used here as a normative basis for describing assumptions about types. The operations and properties described here are compatible with those used in ISO 11404, but not always the same, as 11404 does not use object-oriented functions. For example, the notional function has(x:T) (test for presence of a value in a set) defined on the type Set<T> below is not defined on the ISO 11404 Set type; instead, the function IsIn(x: T; s: Set<T>) is defined. However, in object-oriented formalisms, the function IsIn defined on a Set type would usually mean ‘subset of’. In the interests of clarity for developers, an object-oriented style of functions and properties has been used here.

ISO8601:2004は想定される日時型の定義的な基礎として利用している。それは世界中で一般に広く利用されており、W3C XMLスキーマでもdate/time型の基礎として利用されている。詳細は3.4節を参照することとし、以下に日時についての詳細を示す

ISO8601:2004 is used as the definitional basis for assumed date/time types, since it is commonly used around the world, and is also the basis for the date/time types in W3C XML-schema. See section 3.4 on page 22 below for details of dates and times.

想定される型(assumed type)は二つのグループに識別される。プリミティブ型は形式のための型システムとして組み込まれているものであり、形式で定義される(クラス)ライブラリで利用されると想定されるライブラリ型もそうである。つまり、ブール型は常に形式の中に存在すると想定されており、Array<T>型はライブラリで利用されると想定されている。実用のためには、二つのカテゴリはそう問題とはならない。String型は通常はライブラリ型であるが、それが組み込まれた型であってもプログラマには何の違いももたらさない。ここで二つに分けたのは便宜上の理由である。

Two groups of assumed types are identified: primitive types, which are those built in to a formalism’s type system, and library types, which are assumed to be available in a (class) library defined in the formalism. Thus, the type Boolean is always assumed to exist in a formalism, while the type Array<T> is assumed to be available in a library. For practical purposes, these two categories do not matter that much - whether String is really a library class (the usual case) or an inbuilt type doesn’t make much difference to the programmer. They are shown separately here mainly as an explanatory convenience.

openEHRが既存の型に対して想定していることについては、インターフェースの定義の観点から下記のように記述されている。これらの定義はそれぞれ、openEHRの参照モデル(Reference Model)で使用されている既定の型で必要となると想定されるものだけを収載していて、完全なインターフェース定義というわけではない。想定される型(assumed type)に関連してここで利用されている全ての機能の名前やセマンティクスは、いくつかの実装技術でみられるものとまったく同じではないことがある。なんらかの必要なマッピングについては、関連する実装技術仕様(ITS; Implementation Technology Specification)で示されるべきものである。具体的な例を示すと、以下に想定される型(assumed type)としてSet<T>が定義されていて、has(item: T)という操作を持っているが(Bool型(Boolean)はopenEHR仕様の全てで使われている)、JavaのSet<T>クラスにはcontains()というメソッドがある。Javaで実装する際には、has()メソッドの代わりにcontainsメソッドがJavaで表現されるopenEHRクラスの全てで使用されるはずである。

The assumptions that openEHR makes about existing types are documented below in terms of interface definitions. Each of these definitions contains only the assumptions required for the given type to be used in the openEHR Reference Model -it is not by any means a complete interface definition. The name and semantics of any function used here for an assumed type might not be identical to those found in some implementation technologies. Any mapping required should be stated in the relevant implementation technology specification (ITS). To give a concrete example, where the assumed Set<T> type defined below has an operation has(item: T): Boolean which is used throughout the openEHR specifications, Java has the method contains() on its Set<T> class. In a Java implementation, the contains() method should then be used throughout the openEHR classes as expressed in Java, in place of the has() method.

3.2 組み込みプリミティブ型

3.2 Inbuilt Primitive Types

以下の型はopenEHRの実装形式において想定される最小範囲内のプリミティブ型を構成している。

The following types consititute the minimum set of primitive types assumed by openEHR of an implementation formalism.

openEHRでの型名詳細ISO 11404での型
Octet8ビットの値を表現する型。Octet
Character8ビットの文字セット(ISO: “repertoire”)のメンバーの値を表現する型。Character
Boolean論理的に真/偽値を表現する。通常は物理的には整数で表現されるがそうでなくてもよいBoolean
Integer32ビット整数を表現するInteger
Real32ビット実数をIEEE単精度浮動小数点を含む相互可用性のある表現であらわす。Real
Double64ビット実数を表現する型。IEEEの倍精度浮動小数点を含む何らかの相互可用性を持つ表現をとる。Real
Type name in openEHRDescriptionISO 11404 Type
Octetrepresents a type whose value is an 8-bit value.Octet
Characterrepresents a type whose value is a member of an 8-bit character-set (ISO: “repertoire”).Character
Booleanrepresents logical True/False? values; usually physically represented as an integer, but need not beBoolean
Integerrepresents 32-bit integersInteger
Realrepresents 32-bit real numbers in any interoperable representation, including single-width IEEE floating pointReal
Doubletype which represents 64-bit real numbers, in any interoperable representation including double-precision IEEE floating point.Real


図2は組み込みプリミティブ型を示している。単純継承を使うことで、以下に示す型についての記載を簡単にしている。"Any"クラスは一般的には全てのオブジェクト指向型システムで"Any"あるいは"Object"と呼ばれる最上位のものであることを表している。Anyクラスからの継承あるいはそれに対する大体可能性についてはopenEHRでは想定されていない(したがって、UMLでは点線で示されている)。

FIGURE 2 illustrates the built-in primitive types. Simple inheritance relationships are shown which facilitate the type descriptions below. A class “Any” is used to stand for the usual top-level class in all object-oriented type systems, typically called something like “Any” or “Object”. Inheritance from or subsitutability for an Any class is not assumed in openEHR (hence the dotted lines in the UML). It is used here to enable basic operations like ‘=’ to be described once for the type Any, rather than in every subtype. The type Ordered_numeric is on the other hand assumed for purposes of specification in the openEHR data_types.quantity package, and is intended to be mapped to an equivalent type in a real type system (e.g. in Java, java.lang.Number). Here it is assumed that the operations defined on Ordered_numericare available on the types Integer, Realand Double in implementation type systems, where relevant. Data-oriented implementation type systems such as XML-schema do not have such operations.

Any

Octet

Character

Boolean

Ordered

Numeric

Ordered_numeric

FIGURE 2 Primitive Types Assumed by openEHR

3.2.1 Any Type

INTERFACEAny (abstract)
DescriptionAbstract supertype. Usually maps to a type like “Any” or “Object” in an object system. Defined here to provide the value and reference equality semantics.
AbstractSignatureMeaning
is_equal (other: Any): BooleanValue equality
FunctionsSignatureMeaning
infix ‘=’ (other: Any): BooleanReference equality
instance_of (a_type: String)Dynamic type of object as a String. Used for type name matching.
Invariants

3.2.2 Ordered Type

INTERFACEOrdered (abstract)
PurposeAbstract notional parent class of ordered, types i.e. types on which the ‘<‘ operator is defined.
AbstractSignatureMeaning
infix ‘<’ (other: like Current): BooleanArithmetic comparison. In conjunction with ‘=’, enables the definition of the operators ‘>’, ‘>=’, ‘<=’, ‘<>’. In real type systems, this operator might be defined on another class for comparability.
Invariants

3.2.3 Numeric Type

INTERFACENumeric (abstract)
PurposeAbstract notional parent class of numeric types, which are types which have various arithmetic and comparison operators defined.
AbstractSignatureMeaning

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 15 of 67 Date of Issue:08 Apr 2007

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

Assumed Types Support Information Model Rev 1.6.0

INTERFACENumeric (abstract)
infix "*" (other: like Current): like Current require other_exists: other /= void ensure result_exists: Result /= voidProduct by `other'. Actual type of result depends on arithmetic balancing rules.
infix "+" (other: like Current): like Current require other_exists: other /= void ensure result_exists: Result /= void commutative: equal (Result, other + Current)Sum with `other' (commutative). Actual type of result depends on arithmetic balancing rules.
infix "-" (other: like Current): like Current require other_exists: other /= void ensure result_exists: Result /= voidResult of subtracting `other'. Actual type of result depends on arithmetic balancing rules.
Invariants

3.2.4 Ordered_numeric Type

INTERFACEOrdered_numeric (abstract)
PurposeAbstract notional parent class of ordered, numeric types, which are types with ‘<‘ and arithmetic operators defined.
InheritORDERED, NUMERIC
FunctionSignatureMeaning
Invariants

3.2.5 Boolean Type

INTERFACEBoolean
PurposeBoolean type used for two-valued mathematical logic.
FunctionSignatureMeaning

Date of Issue:08 Apr 2007 Page 16 of 67 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Support Information Model Assumed Types Rev 1.6.0

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

INTERFACEBoolean
infix "and" (other: Boolean): Boolean require other_exists: other /= void ensure de_morgan: Result = not (not Current or not other) commutative: Result = (other and Current)Logical conjunction
infix "and then" (other: Boolean): Boolean require other_exists: other /= void ensure de_morgan: Result = not (not Current or else not other)Boolean semi-strict conjunction with other
infix "or" (other: Boolean): Boolean require other_exists: other /= void ensure de_morgan: Result = not (not Current and not other) commutative: Result = (other or Current) consistent_with_semi_strict: Result implies (Current or else other)Boolean disjunction with other
infix "or else" (other: Boolean): Boolean require other_exists: other /= void ensure de_morgan: Result = not (not Current and then not other)Boolean semi-strict disjunction with `other'
infix "xor" (other: Boolean): Boolean require other_exists: other /= void ensure definition: Result = ((Current or other) and not (Current and other))Boolean exclusive or with `other'

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 17 of 67 Date of Issue:08 Apr 2007

Assumed Types Support Information Model Rev 1.6.0

INTERFACEBoolean
infix "implies" (other: Boolean): Boolean require other_exists: other /= void ensure definition: Result = (not Current or else other)Boolean implication of `other' (semi-strict)
Invariantsinvolutive_negation: is_equal (not (not Current)) non_contradiction: not (Current and (not Current)) completeness: Current or else (not Current)

3.2.6 Real Type

INTERFACEReal
PurposeType used to represent decimal numbers. Typically corresponds to a single-precision floating point value in most languages.
FunctionSignatureMeaning
floor: IntegerReturn the greatest integer no greater than the value of this object.
Invariants

3.3 Assumed Library Types

The types described in this section are also assumed to be fairly standard in implementation technologies by openEHR, but usually come from type libraries rather than being built into the type system of implementation formalisms.

Type name in openEHRDescriptionISO 11404: 2003 Type
Stringrepresents unicode-enabled stringsCharacter-String/Sequence?
Array<T>physical container of items indexed by numberArray
List<T>container of items, implied order, non-unique membershipSequence
Set<T>container of items, no order, unique membershipSet
Hash<T,U:Comparable>a table of values of any type T, keyed by values of any basic comparable type U, typically String or Integer, but may be more complex types, e.g. a coded term type.Table
Interval<T>Intervals with open or closed upper and lower bounds.-

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

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

Support Information Model Assumed Types Rev 1.6.0

FIGURE 3 illustrates the assumed library types. As with the assumed primitive types, inheritance and abstract classes are used for convenience of the definitions below, but are not formally assumed in openEHR.

Any

T

T->Ordered

Aggregate

String

Interval

FIGURE 3 Library Types Assumed by openEHR

3.3.1 String Type

INTERFACEString
DescriptionStrings of characters, as used to represent textual data in any natural or formal language.
FunctionsSignatureMeaning
infix ‘+’ (other: String): StringConcatenation operator - causes ‘other’ to be appended to this string
is_empty: BooleanTrue if string is empty, i.e. equal to “”.
is_integer: BooleanTrue if string can be parsed as an integer.
as_integer: Integer require is_integerReturn the integer corresponding to the integer value represented in this string.
Invariants

3.3.1.1 UNICODE

It is assumed in the openEHR specifications that Unicode is supported by the type String. Unicode is needed for all Asian, Arabic and other script languages, for both data values (particularly plain text and coded text) and for many predefined string attributes of the classes in the openEHR Reference Model. It encompasses all existing character sets. In openEHR, UTF-8 encoding is assumed.

3.3.2 Aggregate Type

Abstract parent of of the aggregate types List<T>, Set<T>, Array<T> and Hash<T,K>.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 19 of 67 Date of Issue:08 Apr 2007

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

Assumed Types Support Information Model Rev 1.6.0

INTERFACEAggregate <T> (abstract)
FunctionsSignatureMeaning
has (v: T): BooleanTest for membership of a value
count: IntegerNumber of items in container
is_empty: BooleanTrue if container is empty.
Invariants

3.3.3 List Type

INTERFACEList <T> (abstract)
DescriptionOrdered container that may contain duplicates.
FunctionsSignatureMeaning
first: TReturn first element.
last: TReturn last element.
InvariantsFirst_validity: not is_empty implies first /= Void Last_validity: not is_empty implies last /= Void

3.3.4 Set Type

INTERFACESet <T> (abstract)
DescriptionUnordered container that may not contain duplicates.
FunctionsSignatureMeaning
Invariants

3.3.5 Array Type

INTERFACEArray <T> (abstract)
DescriptionContainer whose storage is assumed to be contiguous.
FunctionsSignatureMeaning
Invariants

Date of Issue:08 Apr 2007 Page 20 of 67 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Support Information Model Assumed Types Rev 1.6.0

3.3.6 Hash Type

INTERFACEHash <T, U: Comparable>
DescriptionType representing a keyed table of values. T is the value type, and U the type of the keys.
FunctionsSignatureMeaning
has_key (a_key: U): BooleanTest for membership of a key
item (a_key: U): TReturn item for key ‘a_key’. Equivalent to ISO 11404 fetch operation.
Invariants

3.3.7 Interval Type

INTERFACEInterval <T:Ordered>
PurposeInterval of ordered items.
AttributesSignatureMeaning
lower: Tlower bound
upper: Tupper bound
lower_unbounded: Booleanlower boundary open (i.e. = -infinity)
upper_unbounded: Booleanupper boundary open (i.e. = +infinity)
lower_included: Booleanlower boundary value included in range if not lower_unbounded
upper_included: Booleanupper boundary value included in range if not upper_unbounded
FunctionsSignatureMeaning
has(e:T): BooleanTrue if (lower_unbounded or ((lower_included and v >= lower) or v > lower)) and (upper_unbounded or ((upper_included and v <= upper or v < upper)))

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 21 of 67 Date of Issue:08 Apr 2007

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

Assumed Types Support Information Model Rev 1.6.0

Lower_included_valid: lower_unbounded implies not lower_included Upper_included_valid: upper_unbounded implies not upper_included Limits_consistent: (not upper_unbounded and not lower_unbounded) implies lower <= upper Limits_comparable: (not upper_unbounded and not lower_unbounded) implies lower.strictly_comparable_to(upper)

3.4 Date/Time? Types

Although the ISO 11404 (2003) standard defines a date-and-time type generator (section 8.1.6), and a timeinterval type (section 10.1.6), a more widely used specification of date/times is given by ISO !8601:2004, which is used as the normative basis for both string literal representation and properties used within openEHR. The types are shown in FIGURE 4.

Any

Ordered

TIME_DEFINITIONS

ISO 8601 semantics not used in openEHR include:

  • “expanded” dates, which have year numbers of greater than 4 digits, and may be negative; in openEHR, only 4-digit year numbers are assumed;
  • the YYYY-WW-DD method of expressing dates (since this is imprecise and difficult to compute with due to variable week starting dates, and not required in health);
  • partial date/times with fractional minutes or hours, e.g. hh,hhh or mm,mm; in openEHR, only fractional seconds are supported;
  • the interval syntax. Intervals of date/times are supported in openEHR, but their syntax form is defined by ADL, and is standardised across all comparable types, not just dates and times.

Deviations from the published standard include the following:

  • durations are supposed to take the form of PnnW or PnnYnnMnnDTnnHnnMnnS, but in openEHR, the W (week) designator can be used in combination with the other designators, since it is very common to state durations of pregnancy as some combination of weeks and days.
  • partial variants of ISO8601_DATE_TIME can include missing hours, days and months, whereas ISO !8601:2004 (section 4.3.3 c) only allows missing seconds and minutes. The reasons for this deviation are:

Date of Issue:08 Apr 2007 Page 22 of 67 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Support Information Model Assumed Types Rev 1.6.0

-the same deviation is used in HL7v2 and HL7v3 TS (timestamp) type, i.e. there are data in existing clinical systems matching this specification;

-in a typed object model, this deviation is more sensible anyway; the ISO 8601 rule is most likely a limitation of the purely syntactic means of expression. In real systems where a timestamp/date-time is specified in a screen form, it makes sense to allow it to be as partial as possible, rather than artifically restricted to only missing seconds and minutes.

  • the time !24:00:00 (or 240000) is not allowed anywhere, whereas in ISO8601:2004 it appears to be legal at least for times. This deviation is also appears to be used in HL7v2 and HL7v3 (where midnight is defined as the time !00:00:00), and is preferable to the documented standard, since a date/time with time of !24:00:00 is really the next day, i.e. the date part is then incorrect.

The following class definitions provide an object-oriented expression of the semantics of the subset of ISO !8601:2004 used by openEHR.

See http://www.cl.cam.ac.uk/~mgk25/iso-time.html and the official ISO standard for ISO 8601 details. Note that in the date, time and date_time formats shown below, ‘Z’ and ‘T’ are literals. In the duration class shown below, ‘P’, ‘Y’, ‘M’, ‘W’, ‘D’, ‘H’, ‘S’ and ‘T’ are literals.

3.4.1 TIME_DEFINITIONS Class

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

INTERFACETIME_DEFINITIONS
PurposeDefinitions for date/time classes. Note that the timezone limits are set by where the international dateline is. Thus, time in New Zealand is quoted using !+12:00, not !-12:00.
ConstantsSignatureMeaning
1..1Seconds_in_minute: Integer = 60
1..1Minutes_in_hour: Integer = 60
1..1Hours_in_day: Integer = 24
1..1Nominal_days_in_month: Real = 30.42Used for conversions of durations containing months to days and / or seconds.
1..1Max_days_in_month: Integer = 31Used for validity checking.
1..1Days_in_year: Integer = 365
1..1Days_in_leap_year: Integer = 366
1..1Max_days_in_year: Integer = Days_in_leap_yearUsed for validity checking.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 23 of 67 Date of Issue:08 Apr 2007

Assumed Types Support Information Model Rev 1.6.0

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

INTERFACETIME_DEFINITIONS
1..1Nominal_days_in_year: Real = 365.24Used for conversions of durations containing years to days and / or seconds.
1..1Days_in_week: Integer = 7
1..1Months_in_year: Integer = 12
1..1Min_timezone_hour: Integer ensure Result = 12Minimum hour value of a timezone (note that the -ve sign is supplied in the ISO8601_TIMEZONE class).
1..1Max_timezone_hour: Integer ensure Result = 13Maximum hour value of a timezone.
FunctionsSignatureMeaning
valid_year (y: Integer): Boolean ensure Result = y >= 0True if y >= 0
valid_month (m: Integer): Boolean ensure Result = m >= 1 and m <= Months_in_yearTrue if m >= 1 and m <= Months_in_year
valid_day (y, m, d: Integer): Boolean ensure Result = d >= 1 and d <= days_in_month(m, y)True if d >= 1 and d <= days_in_month(m, y)
valid_hour (h, m, s: Integer): Boolean ensure Result = (h >= 0 and h < Hours_in_day) or (h = Hours_in_day and m = 0 and s = 0)True if (h >= 0 and h < Hours_in_day) or (h = Hours_in_day and m = 0 and s = 0)
valid_minute (m: Integer): Boolean ensure Result = m >= 0 and m < Minutes_in_hourTrue if m >= 0 and m < Minutes_in_hour

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

Support Information Model Assumed Types Rev 1.6.0

INTERFACETIME_DEFINITIONS
valid_second (s: Integer): Boolean ensure Result = s >= 0 and s < Seconds_in_minuteTrue if s >= 0 and s < Seconds_in_minute
valid_fractional_second (fs: Double): Boolean ensure Result = fs >= 0.0 and fs < 1.0True if fs >= 0.0 and fs < 1.0
Invariants

3.4.2 ISO8601_DATE Class

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

INTERFACEISO8601_DATE
PurposeRepresents an absolute point in time, as measured on the Gregorian calendar, and specified only to the day.
InheritORDERED, TIME_DEFINITIONS
FunctionSignatureMeaning
as_string: StringISO8601 string for date, in format YYYYMMDD or YYYY-MM-DD, or a partial invariant. See valid_iso8601_date for validity.
year: IntegerYear.
month: Integer require not month_unknownMonth in year.
day: Integerrequire not day_unknownDay in month.
month_unknown: BooleanIndicates whether month in year is unknown. If so, the date is of the form “YYYY”.
day_unknown: BooleanIndicates whether day in month is unknown. If so, and month is known, the date is of the form “YYYY-MM” or “YYYYMM”.
is_partial: BooleanTrue if this date is partial, i.e. if day or more is missing.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 25 of 67 Date of Issue:08 Apr 2007

Assumed Types Support Information Model Rev 1.6.0

INTERFACEISO8601_DATE
is_extended: BooleanTrue if this date uses ‘-’ separators.
infix ‘<’ (other: like Current): BooleanArithmetic comparison with other date. True if this date is closer to the origin than other.
valid_iso8601_dateString is a valid ISO 8601 date, i.e. takes the
(s: String): Booleancomplete form: • YYYYMMDD or the extended form: • YYYY-MM-DD or one of the partial forms: • YYYYMM • YYYY or the equivalent extended form: • YYYY-MM Where: • YYYY is the string form of any positive number in the range “0000” - “9999” (zero-filled to four digits) • MM is “01” “12” (zero-filled to two digits) • DD is “01” - “31” (zero-filled to two digits) The combinations of YYYY, MM, DD numbers must be correct with respect to the Gregorian calendar.
InvariantsYear_valid: valid_year(year) Month_valid: not month_unknown implies valid_month(month) Day_valid: not day_unknown implies valid_day(year, month, day) Partial_validity: month_unknown implies day_unknown

3.4.3 ISO8601_TIME Class

INTERFACEISO8601_TIME
PurposeRepresents an absolute point in time from an origin usually interpreted as meaning the start of the current day, specified to the second. A small deviation to the ISO !8601:2004 standard in this class is that the time !24:00:00 is not allowed, for consistency with ISO8601_DATE_TIME.
InheritORDERED, TIME_DEFINITIONS
FunctionSignatureMeaning

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

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

Support Information Model Assumed Types Rev 1.6.0

INTERFACEISO8601_TIME
as_string: StringISO8601 string for time, i.e. in form: hhmmss[,sss][Z|±hh[mm]] or the extended form: hh:mm:ss[,sss][Z|±hh[mm]], or a partial invariant. See valid_iso8601_time for validity.
hour: IntegerHour in day, in 24-hour time.
minute: Integer require not minute_unknownMinute in hour.
second: Integer require not second_unknownSecond in minute.
fractional_second: Double require not second_unknownFractional seconds.
has_fractional_second: BooleanTrue if the fractional_second part is signficant (i.e. even if = 0.0).
timezone: ISO8601_TIMEZONE minute_unknown: BooleanTime zone; may be Void. Indicates whether minute is unknown. If so, the time is of the form “hh”.
second_unknown: BooleanIndicates whether second is unknown. If so and month is known, the time is of the form “hh:mm” or “hhmm”.
is_partial: BooleanTrue if this time is partial, i.e. if seconds or more is missing.
is_extended: BooleanTrue if this time uses ‘:’ separators.
is_decimal_sign_comma: BooleanTrue if this time has a decimal part indicated by ‘,’ (comma) rather than ‘.’ (period).
infix ‘<’ (other: like Current): BooleanArithmetic comparison with other time. True if this date is closer to previous midnight than other.

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

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

Assumed Types Support Information Model Rev 1.6.0

INTERFACEISO8601_TIME
valid_iso8601_timeString is a valid ISO 8601 date, i.e. takes the
(s: String): Booleanform: • hhmmss[,sss][Z | ±hh[mm]] or the extended form: • hh:mm:ss[,sss][Z | ±hh[mm]] or one of the partial forms: • hhmm or hh or the extended form: • hh:mm with an additional optional timezone indicator of: • Z or ±hh[mm] Where: • hh is “00” - “23” (0-filled to two digits) • mm is “00” - “59” (0-filled to two digits) • ss is “00” - “60” (0-filled to two digits) • sss is any numeric string, representing an optional fractional second • Z is a literal meaning UTC (modern replacement for GMT), i.e. timezone +0000 • ±hh[mm], i.e. +hhmm, +hh, -hhmm, -hh indicating the timezone.
InvariantsHour_valid: valid_hour(hour, minute, second) Minute_valid: not minute_unknown implies valid_minute(minute) Second_valid: not second_unknown implies valid_second(second) Fractional_second_valid: has_fractional_second implies (not second_unknown and valid_fractional_second(fractional_second)) Partial_validity: minute_unknown implies second_unknown

3.4.4 ISO8601_DATE_TIME Class

INTERFACEISO8601_DATE_TIME
PurposeRepresents an absolute point in time, specified to the second. Note that this class includes 2 deviations from ISO !8601:2004: • for partial date/times, any part of the date/time up to the month may be missing, not just seconds and minutes as in the standard; • the time !24:00:00 is not allowed, since it would mean the date was really on the next day.
InheritORDERED, TIME_DEFINITIONS
FunctionSignatureMeaning

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

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

Support Information Model Assumed Types Rev 1.6.0

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

INTERFACEISO8601_DATE_TIME
as_string: String ensure valid_iso8601_date_time(Result)ISO8601 string for date/time, in format YYYYMMDDThhmmss[,sss][Z | ±hh[mm]] or in extended format YYYY-MM-DDThh:mm:ss[,sss][Z | ±hh[mm]] or a partial variant; see valid_iso8601_date_time() below.
year: Integeryear
month: Integerrequire not month_unknownmonth in year
day: Integerrequire not day_unknownday in month
hour: Integerrequire not hour_unknownhour in day
minute: Integer require not minute_unknownminute in hour
second: Integerrequire not second_unknownsecond in minute
fractional_second: Double require has_fractional_secondfractional seconds
has_fractional_second: BooleanTrue if the fractional_second part is signficant (i.e. even if = 0.0).
timezone: ISO8601_TIMEZONETimezone; may be Void.
month_unknown: BooleanIndicates whether month in year is unknown.
day_unknown: BooleanIndicates whether day in month is unknown.
hour_unknown: BooleanIndicates whether hour in day is known.
minute_unknown: BooleanIndicates whether minute in hour is known.
second_unknown: BooleanIndicates whether minute in hour is known.
is_partial: BooleanTrue if this date is partial, i.e. if seconds or more is missing.

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

Assumed Types Support Information Model Rev 1.6.0

INTERFACEISO8601_DATE_TIME
is_decimal_sign_comma: BooleanTrue if this time has a decimal part indicated by ‘,’ (comma) rather than ‘.’ (period).
infix ‘<’ (other: like Current): BooleanArithmetic comparison with other date/time. True if this date/time is closer to origin than other.
is_extended: BooleanTrue if this date/time uses ‘-’, ‘:’ separators.
valid_iso8601_date_timeString is a valid ISO 8601 date-time, i.e.
(s: String): Booleantakes the form: • YYYYMMDDThhmmss[,sss] [Z | ±hh[mm]] or the extended form: • YYYY-MM-DDThh:mm:ss[,sss] [Z | ±hh[mm]] or one of the partial forms: • YYYYMMDDThhmm • YYYYMMDDThh or the equivalent extended forms: • YYYY-MM-DDThh:mm • YYYY-MM-DDThh (meanings as in DV_DATE, DV_TIME) and the values in each field are valid.
InvariantsYear_valid: valid_year(year) Month_valid: valid_month(month) Day_valid: valid_day(year, month, day) Hour_valid: valid_hour(hour, minute, second) Minute_valid: not minute_unknown implies valid_minute(minute) Second_valid: not second_unknown implies valid_second(second) Fractional_second_valid: has_fractional_second implies (not second_unknown and valid_fractional_second(fractional_second)) Partial_validity_year: not month_unknown Partial_validity_month: not month_unknown Partial_validity_day: not day_unknown Partial_validity_hour: not hour_unknown Partial_validity_minute: minute_unknown implies second_unknown

3.4.5 ISO8601_TIMEZONE Class

Date of Issue:08 Apr 2007 Page 30 of 67 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Support Information Model Assumed Types Rev 1.6.0

INTERFACEISO8601_TIMEZONE
InheritTIME_DEFINITIONS
FunctionSignatureMeaning
as_string: StringISO8601 timezone string, in format • Z | ±hh[mm] where: • hh is “00” - “23” (0-filled to two digits) • mm is “00” - “59” (0-filled to two digits) • Z is a literal meaning UTC (modern replacement for GMT), i.e. timezone +0000
hour: IntegerHour part of timezone - in the range 00 - 13
minute: Integer require not minute_unknownMinute part of timezone. Generally 00 or 30.
sign: IntegerDirection of timezone expresssed as +1 or -1.
is_gmt: BooleanTrue if timezone is UTC, i.e. +0000
minute_unknown: BooleanIndicates whether minute part known.
InvariantsMin_hour_valid: sign = -1 implies hour > 0 and hour <= Min_timezone_hour Max_hour_valid: sign = 1 implies hour > 0 and hour <= Max_timezone_hour Minute_valid: not minute_unknown implies valid_minute(minute) Sign_valid: sign = 1 or sign = -1

3.4.6 ISO8601_DURATION Class

INTERFACEISO8601_DURATION
PurposeRepresents a period of time corresponding to a difference between two time-points.
InheritORDERED, TIME_DEFINITIONS
FunctionSignatureMeaning
as_string: StringISO8601 string for duration, in format • P[nnY][nnM][nnW][nnD][T[nnH][nnM][nnS]]
years: Integernumber of years of nominal 365-day length
months: Integernumber of months of nominal 30 day length
weeks: Integernumber of 7 day weeks

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 31 of 67 Date of Issue:08 Apr 2007

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

Assumed Types Support Information Model Rev 1.6.0

INTERFACEISO8601_DURATION
days: Integernumber of 24 hour days
hours: Integernumber of 60 minute hours
minutes: Integernumber of 60 second minutes
seconds: Integernumber of seconds
fractional_second: Doublefractional seconds
infix ‘<’ (other: like Current): BooleanArithmetic comparison with other duration. True if this duration is smaller than other.
valid_iso8601_duration (s: String): BooleanString is a valid ISO 8601 duration, i.e. takes the form: • P[nnY][nnM][nnW][nnD][T[nnH][nnM][nnS]] Where each nn represents a number of years, months, etc. nnW represents a number of 7day weeks. Note: allowing the W designator in the same expression as other designators is an exception to the published standard, but necessary in clinical information (typically for representing pregnancy duration).
is_decimal_sign_comma: BooleanTrue if this time has a decimal part indicated by ‘,’ (comma) rather than ‘.’ (period).
to_seconds: DoubleTotal number of seconds equivalent (including fractional) of entire duration.
Invariantsyears_valid: years >= 0 months_valid: months >= 0 weeks_valid: weeks >= 0 days_valid: days >= 0 hours_valid: hours >= 0 minutes_valid: minutes >= 0 seconds_valid: seconds >= 0 fractional_second_valid: fractional_second >= 0.0 and fractional_second < 1.0

Date of Issue:08 Apr 2007 Page 32 of 67 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

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

Support Information Model Identification Package Rev 1.6.0


  1. 1. 本仕様書には data types とあるが、ISO 11404のドキュメント内部にはDatatypesと表現されている。ここではISO 11404の表記を優先した

TOC PREV NEXT

Last modified 10 years ago Last modified on Oct 12, 2008, 6:00:12 PM