支持信息模型

发行人：openEHR规范程序

发布：版本1.0.3

状态：STABLE

修订：[latest_issue]

日期：[latestissuedate]

关键词：EHR，openehr，标识符，类型

©2003 - 2015 openEHR基金会

openEHR基金会是一个独立的非营利社区组织，通过开源，基于标准的实施，促进消费者和临床医生共享健康记录。

• 许可
  • Creative Commons Attribution-NoDerivs 3.0 Unported。 https://creativecommons.org/licenses/by-nd/3.0/
• 支持
  • 问题：https：//openehr.atlassian.net/browse/SPECPR/
  • 网址：http：//www.openehr.org/

修订记录

• R E L E A S E 1.0.3
  • 1.7.0 (2015年8月15日)
    • SPECRM-29：将DV_COUNT.magnitude更改为integer64类型。
  • 1.7.0 (2015年10月10日)
    • SPECRM-31：升级INTERNET_ID语法以允许下划线;清理EBNF。
• R E L E A S E 1.0.2
  • 1.6.1 (2008年10月20日)
    • SPEC-256：更正UIDBASEDID类中的extension_validity。
    • SPEC-260：更正为ARCHETYPE_ID类型发布的正则表达式。改进了复合标识符的说明文本，包括对区分大小写的说明。警告包括.v1draft不符合。
• R E L E A S E 1.0.1
  • 1.6.0 (2007年4月8日)
    • CR-000215：合并DVPARTIALXX日期/时间类，并将ISO 8601语义移动到支持IM。
    • CR-000209：进行次要更改以正确定义AUTHOREDRESOURCE.currentrevision。为List 类添加最小定义。
    • CR-000200：正确的1.0版排字错误。将INTERVAL类定义移动到正确的部分。添加两个不变量。改进标识符的说明。
    • CR-000202：更正VERSION.precedingversionid中的小错误。添加了is_first函数，并且不变为VERSIONTREEID类。添加了基于1的编号的不变量
    • CR-000203：1.0版说明文字改进。
    • CR-000204：添加OBJECT_ID的通用id子类型。
    • CR-000216：允许在ISO8601中的W，D等的混合持续时间（与标准偏差）。
    • CR-000219：使用常量而不是文字来引用RM中的术语。
    • CR-000220：拧紧HISTORY.period和EVENT.time的语义。
    • CR-000144：添加新比率类型：DV_PROPORTION。添加Real.floor。
    • CR-000221.将normalstatus添加到DVORDERED。调整不变量。
    • CR-000228：将ISO 8601的微小偏差添加到假定的日期/时间类型。
    • CR-000229：次要日期/时间更正。允许2位时区。
    • CR-000236：在DV_MULTIMEDIA中将字符的使用更改为八位位组。
    • CR-000239：添加OBJECTVERSIONID和HIEROBJECTID的公共父类型。
    • CR-000243：将template_id添加到ARCHETYPED类。
    • CR-000246：更正openEHR术语表。
• R E L E A S E 1.0
  • 1.5 (2006年2月06日)
    • CR-000162.没有人口统计数据时允许方标识符。在PARTY_REF上保持不变。
    • CR-000184.将术语从支持IM分离出来。
    • CR-000188：将generate_type函数添加到ANY以在不变量中使用。
    • CR-000161.支持分布式版本控制。将OBJECTID.version移动到子类型。添加OBJECTVERSIONID，VERSIONTREEID和LOCATABLEREF类型。
• R E L E A S E 0.96
  • 1.3 (2005年6月25日)
    • CR-000135：对rm.support.terminology包的微小更正。
    • CR-000126.部分日期/时间类的正确详细信息。
    • CR-000112.添加DVPARTIALDATE_TIME类
• R E L E A S E 0.95
  • 1.2.1 (2005年2月25日)
    • CR-000129.修复标识包的UML和规格中的错误。调整OBJECTID，HIEROBJECTID，ARCHETYPEID和TERMINOLOGYID的不变量和后置条件。改进文本与假定的抽象类型Any和Orderednumeric。
  • 1.2 (2005年2月10日)
    • CR-000128.更新支持假设类型为ISO 11404：2003.
    • CR-000107.添加对排除和包含间隔限制的支持。
    • CR-000116.添加PARTICIPATION.function词汇和不变。
    • CR-000122.在支持模型中的Terminology_access类中修复UML。
    • CR-000118.使包名称为小写。
    • CR-000111.将标识包移动到支持。
    • CR-000064.重新评估COMPOSITION.is_persistent属性。添加“组合类别”词汇表。按字母顺序重新排序词汇。
• R E L E A S E 0.9
  • 1.1 (2004年3月11日)
    • CR-000047.改进结构属性代码的处理。填充术语和code_set代码。
  • 1.0 (2004年3月09日)
    • CR-000091.纠正使用CODEPHRASE和DVCODED_TEXT时的异常。添加简单术语服务接口。
    • CR-000095.从数量包中删除属性属性。添加简单的测量界面。
    • 使用ISE Eiffel 5.4正式验证。
  • 0.9.9 （13 Feb 2004）
    • CR-000063. ATTESTATION应该有一个状态属性。
  • 0.9.8 （20 Dec 2003）
    • CR-000068.纠正INTERVAL类中的错误。
  • 0.9.7 （2003年10月9日）
    • CR-000032.基本数字类型假设需要说明。
    • CR-000041.在openEHR文档中可视化区分基本类型。
    • CR-000043.将外部包移动到Common RM并重命名为Identification（包含CR-000036 - - 添加HIEROBJECTID类，使OBJECT_ID类抽象）。
  • 0.9.6 （2003年9月18日）
    • CR-000013.重命名键类。基于CEN ENV13606.
    • CR-000038.从多轴原型ID中删除archetype_originator。
    • CR-000039.将archetype_id节分隔符从“：”更改为“ - ”。
  • 0.9.5 （16 August 2003）
    • CR-000036.添加HIEROBJECTID类，使OBJECT_ID类抽象。
  • 0.9.4 （2003年6月20日）
    • CR-000022.代码TERM_MAPPING.purpose。
  • 0.9.3 （2003年4月11日）
    • CR-000007.添加了Subjectrelationships和Providerfunctions的已忘记术语。
  • 0.9.2 （2003年3月25日）
    • 海洋，DSTC，Grahame Grieve的详细审查。更新了OBJECT_ID.namespace中的有效字符。
  • 0.9.1 （2003年3月18日）
    • 添加了BOOLEAN类型的规格。修正ISO 639标准字符串中的小错误 - 现在符合TERMINOLOGYID。 OBJECTID.version_id现在是可选的。改进的文档结构。
  • 0.9 （2003年2月25日）
    • 初始写作。取自数据类型和通用参考模型。使用ISE Eiffel 5.2正式验证。

致谢

本文件所报告的工作由下列组织提供资金：

• 伦敦大学学院 - 健康信息学和多专业教育中心（CHIME）;

• 海洋信息;

• 分布式系统技术中心（DSTC），通过澳大利亚联邦政府总理和内阁部合作研究中心计划。

特别感谢CHIME负责人David Ingram教授，他提供了自GEHR（1992年）时代以来的愿景和合作的工作环境。

1.前言

1.1.目的

本文档描述了openEHR支持信息模型，其语义由所有openEHR参考模型使用。

目标受众包括：

• 生产卫生信息学标准的标准机构;

• 使用openEHR的学术团体;

• 开源医疗保健社区;

• 解决方案供应商;

• 医疗信息学家和临床医生对健康信息感兴趣。

1.2.相关文件

阅读本文档的前提条件包括：

• openEHR架构概述（[openehr_overview]）;

1.3.状态

此规范处于STABLE状态。本文档的开发版本可以在http://www.openehr.org/releases/RM/latest/support.html找到。

已知的遗漏或问题在文本中用“待定”段落表示，如下：

TBD :(例如待定段落）

鼓励用户对这些段落以及主要内容发表评论和/或建议。应在技术邮件列表或规格问题跟踪器上提供反馈。

1.4.一致性

数据或软件工件与openEHR参考模型规范的一致性通过该工件相对于相关openEHR实现技术规范（ITS）（例如IDL接口或XML模式）的形式测试来确定。由于ITS是来自参考模型的形式化的自动推导，ITS一致性指示RM一致性。

2.支持包

2.1.概述

支持参考模型包括在openEHR模型中使用的类型，包括在openEHR之外定义的假设的原始类型。封装结构如下图所示。假定类型“伪包”表示由openEHR规范假设存在于诸如编程语言，模式语言或数据库环境的实现技术中的类型。四个支持包分别定义常量，术语访问，对外部定义的科学单位的访问和转换信息的语义。类EXTERNALENVIRONMENTACCESS是一个mixin类，提供对服务接口类的访问。

2.2.类定义

2.2.1. EXTERNALENVIRONMENTACCESS类

3.假设类型

3.1.概述

本节介绍所有openEHR模型假设的类型。这里选择的一组类型基于来自各种公开来源的公共集，包括：

• ISO 11404（2003修订版）通用数据类型;

• ISO 8601（2004）日期/时间规范;

• 众所周知的互操作性形式，包括OMG IDL，W3C XML模式;

• 着名的面向对象编程语言，包括Java，C＃，C ++和Eiffel。

openEHR的目的是双重的。首先，为了确保基于模型的openEHR软件尽可能容易地与现有的实现技术集成，其次，对实现形式中发现的类型做出最小可能的假设，同时做出足够的假设以使得能够方便地指定openEHR模型。 ISO 11404（2003）标准包含用于信息技术的“通用数据类型”（GPD）的基本语义，并且在此用作描述关于类型的假设的规范基础。这里描述的操作和属性与ISO 11404中使用的操作和属性兼容，但不总是相同，因为11404不使用面向对象的函数。例如，在ISO 11404集合类型上没有定义下面类型集合上定义的名义函数（x：T）（测试集合中是否存在值）而是定义函数IsIn（x：T; s：Set ）。然而，在面向对象的形式主义中，在Set类型上定义的函数IsIn通常意味着'的子集。为了清楚起见，在这里已经使用了面向对象的函数和属性的样式。

ISO8601：2004用作假定日期/时间类型的定义基础，因为它通常在世界各地使用，并且也是W3C XML模式中日期/时间类型的基础。有关日期和时间的详细信息，请参阅下面的日期/时间类型。

确定了两组假设类型：原始类型，它们是构建在形式主义的类型系统中的类型;以及库类型，它们被假定为在形式主义中定义的（类）库中可用。因此，类型布尔值总是假定以形式主义存在，而类型Array 假设在库中可用。出于实际目的，这两个类别无关紧要 - 无论String是真正的库类（通常情况）还是内置类型对程序员没有太大的区别。它们在这里主要作为说明方便而单独示出。

openEHR对现有类型做出的假设在接口定义方面记录如下。这些定义中的每一个仅包含在openEHR参考模型中使用的给定类型所需的假设 - 它绝不是一个完整的接口定义。此处用于假设类型的任何函数的名称和语义可能与某些实现技术中发现的函数不同。任何所需的映射都应在相关实施技术规范（ITS）中说明。为了给出一个具体的例子，在下面定义的假定的Set 类型具有操作具有（item：T）：Boolean，其在整个openEHR规范中使用，Java在其Set 类上具有方法contains（）。在Java实现中，应该使用以Java表示的openEHR类中的contains（）方法来代替has（）方法。

3.2.内置原始类型

以下类型构成了实现形式主义的openEHR假定的最基本类型集合。

下图说明了内置的基本类型。显示了简化的继承关系，这有助于下面的类型描述。类“Any”用于代表所有面向对象类型系统中通常的顶级类，通常称为“Any”或“Object”。在OpenEHR中不假定Any类的继承或成员性（因此在UML中的虚线）。它在这里用于启用基本操作，例如'='一次描述一次类型Any，而不是每个子类型。另一方面，类型Orderednumeric在openEHR datatypes.quantity包中用于指定的目的，并且旨在映射到真实类型系统（例如，Java，java.lang.Number）中的等效类型。这里假定在相关的实现类型系统中，在Ordered_numeric上定义的操作可用于Integer，Real和Double类型。面向数据的实现类型系统（如XML模式）没有这样的操作。

3.2.1.Any类

3.2.2.Numeric类

3.2.3.Ordered类

3.2.4. Ordered_Numeric类

3.2.5.Boolean类

infix和（other：Boolean）：Boolean
Post_de_Morgan：结果=不（不是自己或不是其他）
Post_commutative：Result =（other和self）

infix and_then（other：Boolean）：Boolean
Post_de_Morgan：Result = not（not self或else not other）

infix或（other：Boolean）：Boolean
Post_de_Morgan：Result = not（not self and not other）
Post_commutative：Result =（other或Current）
Post_consistent_with_semi_strict：结果暗示（self或else其他）

infix or_else（other：Boolean）：Boolean
Post_de_Morgan：Result = not（not self，then not other）

infix xor（other：Boolean）：Boolean
Post_definition：Result = self或other）而不是（self和other

infix implies（other：Boolean）：Boolean
Post_definition：Result =（not self或else other）

3.2.6.Integer类

3.2.7. Integer64类

3.2.8.Real类

3.3.假设库类型

本节中描述的类型也被假定为在openEHR的实现技术中相当标准，但通常来自类型库，而不是内置到实现形式的类型系统中。

以下UML图说明了假定的库类型。与假定的基本类型一样，为了方便下面的定义，使用继承和抽象类，但是在openEHR中没有正式假定。

3.3.1.String类

3.3.2.Aggregate类

3.3.3.List类

3.3.4.Set类

3.3.5.Array类

3.3.6.Hash类

3.3.7.Interval类

3.4. 日期/时间类型

虽然ISO 11404（2003）标准定义了日期和时间类型发生器（8.1.6节）和时间间隔类型（10.1.6节），但更广泛使用的日期/时间规范由ISO 8601给出： 2004，它被用作openEHR中使用的字符串字面表示和属性的规范基础。 类型在下面的UML图中显示。

openEHR中未使用的ISO 8601语义包括：

• “扩展”日期，年份数字大于4位数，可能为负数;在openEHR中，假设只有4位数年份数字;

• 表示日期的YYYY-WW-DD方法（因为由于变量星期开始日期，并且健康中不需要，因此这是不精确和难以计算的）;

• 具有分数分钟或小时的部分日期/时间，例如hh，hhh或mm，mm;在openEHR中，只支持小数秒;

• 间隔语法。 openEHR支持日期/时间的间隔，但是它们的语法形式由ADL定义，并且在所有可比较类型中标准化，而不仅仅是日期和时间。

与公布标准的偏差包括以下内容：

• 持续时间应采取PnnW或PnnYnnMnnDTnnHnnMnnS的形式，但在openEHR中，W（周）指示符可以与其他指示符组合使用，因为将妊娠持续时间描述为几周和几天的某些组合是非常常见的。

• ISO8601DATETIME的部分变体可能包括缺少的小时，天和月，而ISO 8601：2004（第4.3.3 c节）仅允许缺少秒和分钟。这种偏差的原因是：

  • 在HL7v2和HL7v3TS（时间戳）类型中使用相同的偏差，即在与该规范匹配的现有临床系统中存在数据;

  • 在类型化对象模型中，这种偏差更加明智; ISO 8601规则最有可能是纯语法表达手段的限制。在实际系统中，以屏幕形式指定时间戳/日期时间，允许它尽可能地局部是有意义的，而不是仅限于缺少秒和分钟。

• 时间24:00:00（或240000）不允许在任何地方，而在ISO8601：2004它似乎是合法的，至少对于时间。该偏差也出现在HL7v2和HL7v3中（其中午夜定义为时间00:00:00），并且优于已记录的标准，因为具有24:00:00的时间的日期/时间真的是第二天，即日期部分不正确。

以下类定义提供了openEHR使用的ISO 8601：2004子集的语义的面向对象表达式。

有关ISO 8601的详细信息，请参见http://www.cl.cam.ac.uk/~mgk25/iso-time.html和官方ISO标准。请注意，在下面显示的日期，时间和日期_时间格式中，“Z”和“T”是文字。在下面所示的持续时间类别中，“P”，“Y”，“M”，“W”，“D”，“H”，“S”和“T”

3.4.1. TIME_DEFINITIONS类

valid_year（y：Integer）：Boolean
Post：Result = y> = 0

valid_month（m：Integer）：Boolean
发布：结果= m> = 1和m⇐Months_in_year

valid_day（y：Integer，m：Integer，d：Integer）：Boolean
Post：Result = d> = 1 andd⇐days_in_month（m，y）

valid_hour（h，m，s：Integer）：Boolean
Post：Result =（h> = 0和h 
		

valid_minute（m：Integer）：Boolean
后：结果= m> = 0和m 
		

valid_second（s：Integer）：Boolean
发布：结果= s> = 0和s 
		

valid_fractional_second（fs：Double）：Boolean
Post：Result = fs> = 0.0和fs <1.0.

3.4.2. ISO8601_TYPE类

3.4.3. ISO8601_DATE类

如果此日期使用“ - ”分隔符，则为true。


valid_iso8601_date：Boolean


字符串是有效的ISO 8601日期，即采用完整的形式：

    YYYYMMDD或扩展形式：

    YYYY-MM-DD或部分形式之一：

    YYYYMM

    YYYY

或等效扩展形式：

    YYYY-MM

哪里：

    YYYY是范围“0000” - “9999”（零填充到四个数字）中任何正数的字符串形式，

    MM为“01” - “12”（零填充为两位数）

    DD是“01” - “31”（填零到两位数）

相对于公历，YYYY，MM，DD数字的组合必须正确。

3.4.4. ISO8601_TIME类

表示从原点开始的绝对时间点，通常被解释为当前日期的开始，指定为第二天。
注意
在本课程中，与ISO 8601：2004标准的小偏差是，为了与ISO8601_DATE_TIME一致，不允许24:00:00的时间。

fractional_second：Real
前：不是second_unknown

String是有效的ISO 8601日期，即采用以下格式：

    hhmmss [，sss] [Z | hh[mm]

或扩展形式：

    hh：mm：ss [，sss] [Z | ±hh [mm]]

或部分形式之一：

    hhmm或hh

或扩展形式：

    hh：mm

带有附加的可选时区指示器：* Z或hh[mm]

哪里：

    hh是“00” - “23”（0填充两位数）

    mm为“00” - “59”（0填充两位数）

    ss为“00” - “60”（0填充两位数）

    sss是任何数字字符串，表示可选的小数秒

    Z是字面意思UTC（现代替代GMT），即时区+0000

    hh[mm]，即+ hhmm，+ hh，-hhmm，-hh，表示时区

3.4.5. ISO8601DATETIME类

表示指定给秒的绝对时间点。

请注意，此类别包括ISO 8601：2004的2个偏差：

    对于部分日期/时间，直到该月的日期/时间的任何部分可能丢失，而不仅仅是标准中的秒和分钟;

    时间24:00:00不允许，因为这意味着日期真的在第二天。

月：整数
前：not month_unknown

day：整数
前：not day_unknown

小时：整数
前：不是hour_unknown

分钟：整数
前：not minute_unknown

second：Integer
前：不是second_unknown

如果此时间具有由“，”（逗号）表示的小数部分，而不是“。”（句点），则为true。


时区：ISO8601_TIMEZONE


时区;可以为空。

ISO8601日期/时间字符串，格式为YYYYMMDDThhmmss [，sss] [Z | ±hh [mm]]或扩展格式YYYY-MM-DDThh：mm：ss [，sss] [Z | ±hh [mm]]或部分变体;请参阅下面的valid_iso8601_date_time（）。

String是有效的ISO 8601日期时间，即采用以下形式：

    YYYYMMDDThhmmss [，sss] [Z | hh[mm]

或扩展形式：

    YYYY-MM-DDThh：mm：ss [，sss] [Z | hh[mm]

或部分形式之一：

    YYYYMMDDhmmmm

    YYYYMMDDThh

或等效的扩展形式：

    YYYY-MM-DDThh：mm

    YYYY-MM-DDThh

（含义如DV_DATE，DV_TIME），并且每个字段中的值有效。

3.4.6. ISO8601_DURATION课程

ISO8601字符串的格式

    P [nnY] [nnM] [nnW] [nnD] [T [nnH] [nnM] [nnS]]

3.4.7. ISO8601_TIMEZONE类

ISO8601时区字符串，格式如下：

    Z | hh[mm]

哪里：

    hh是“00” - “23”（0填充两位数）

    mm为“00” - “59”（0填充两位数）

    Z是字面意思UTC（现代替代GMT），即时区+0000

4.识别包

4.1.概述

rm.support.identification包描述了信息实体的引用和标识符模型，如下所示。

4.1.1.要求

在现实世界和信息系统中识别实体是一个非平凡的问题。在健康信息环境中跨系统识别的需求包括以下：

• 诸如社会安全号码，退伍军人事务id等真实世界标识符可以按照医疗保健设施，企业政策或立法的要求记录;

• 表示真实世界实体或过程的信息实体的标识符应该是唯一的;

• 应该可以确定两个标识符是否指代表示相同现实世界实体的信息实体，即使信息实体的实例被保持在不同的系统中;

• 对现实世界实体链接的信息实体（其可以创建新的信息实例）的版本或改变应该以两种方式来解释：

  • 应该可以判断两个标识符是否指向同一版本树中的相同信息实体的不同版本;

  • 应该不可能混淆在多个系统中维护的旨在表示相同真实世界实体的信息实体的同名版本。例如。不能保证两个系统的“最新”版本的“琼斯博士”是相同的。

  • 医学法律使用信息依赖于先前的信息状态可与其他先前状态和当前状态区分开。

• 一个系统或服务（例如EHR）中的实体应该可以以下述方式引用另一个系统或服务中的实体：

  • 参考的目标在共享环境中是容易可靠的

  • 无论服务器和应用程序的物理体系结构如何，引用都是有效的。

以下小节描述了识别的一些特征和挑战。

现实世界实体（RWE）

诸如人，汽车引擎，发票和约会的现实世界实体都可以被分配标识符。虽然其中许多设计为在一个管辖区内是唯一的，但由于数据输入错误，不良设计（ids太小或包含所标识实体的一些非唯一特性），坏进程（例如， - 同步的id发布点）;身份盗用（例如通过窃取证明文件或黑客入侵）。一般来说，虽然一些真实世界标识符（RWI）是“几乎唯一的”，但没有一个可以保证这样。也应该是这样的情况，如果两个RWE标识符相等，它们指的是相同的RWE，但通常不是这样。出于实际目的，RWI不能被认为对于进行这里描述的推论是计算安全的。 信息实体（IE）

一旦信息系统被用于记录关于RWE的事实，由于信息的无形性质，情况变得更加复杂。尤其是：

• 相同的RWE可以在多于一个系统上同时表示（“空间多重性”）;

• 相同的RWE可以由系统中的同一IE的多于一个“版本”（“时间多重性”）来表示。

初看起来，似乎还可以存在纯信息实体，即不涉及任何RWE的IE，例如书，仅在线的文档和软件。然而，一旦考虑一个例子，变得清楚的是总是存在每个这样的实体的虚拟的“确定的”或“权威的”（即可信的）版本。这些实体可以更好地被理解为“虚拟RWE”。因此，仍然可以说多个IE可以指任何给定的RWE。

IE的多样性的根本原因是计算机系统中的“现实” - 时间和空间不是连续的，而是离散的，并且每个“实体”实际上只是RWE的某些属性值的快照，时间，在一个特定的系统。如果将标识符分配给IE而不考虑版本或重复，则当比较两个IEid时，不能对所识别的RWE进行断言。 版本的标识

“版本化”的概念仅适用于信息实体，即，每个表示一些逻辑实体的快照的内容的不同实例。在这种实例在某种版本系统内的版本化容器中存储和管理的情况下，需要明确地识别版本。这些要求在Common IM，change_control包中详细讨论。

它们可以总结如下：

• 必须能够区分同一逻辑实体的两个版本，即如果它们是同一事物的相同或不同版本，则从标识符知道;

• 必须能够区分在两个不同系统中创建的相同逻辑实体的两个版本;

• 必须能够从版本标识符中识别版本化谱系中的项目之间的关系。

参考信息实体

在分布式信息环境中，需要在相同存储器空间中不通过直接引用连接的实体能够彼此引用。有两个竞争要求：*在分布式计算环境中对象的分离不会影响模型的语义; *不同类型的信息可以相对独立地管理;例如EHR和人口统计信息可以由组织或社区中的不同群组管理，每个群组至少具有改变实现和模型细节的一些自由。

4.2.设计

该包仅仅建模信息标识符，即openEHR或相​​关计算系统理解的透明标识符。真实世界实体标识符（例如驾驶执照号）使用数据类型DV_IDENTIFIER建模。这并不意味着这样的标识符比这里定义的系统标识符更少系统化或良好管理，只是从openEHR的观点来看，它们具有与其他信息属性相同的状态，例如名称，地址等人。

关键设计决定是为所有标识符选择一个字符串表示，子部分由对字符串执行简单解析的适当函数提供。这确保了标识符的数据表示（例如，在XML中）尽可能小，而不会失去面向对象的打字。

4.2.1.原始标识符

在这个包中定义了三种类型。抽象UID类型及其子类型对应于永久的，计算可靠的基本标识符。这样的标识符被认为是“原始的”，因为它们被视为不具有进一步的内部结构，在这种标识符的一部分通常不是有意义的意义上。三个子类型UUID，ISOOID和INTERNETID都具有这些属性，并且是在计算机系统中唯一地识别实体的通常接受的方式。在openEHR（通常在健康信息学中），它们通常用作其他标识符的一部分。

在这些类中使用的字符串表示方法的结果是，从字符串值设置类型UID的属性，如从数据库读取时所做的那样，从XML或另一文本形式解析，一段代码检查字符串结构必须被使用为了决定它的UID的子类型。这是一个安全的事情，因为所有三个子类型具有互斥的字符串模式，并且可以容易地区分。

4.2.2.复合标识符

OBJECTID类型及其子类型的层次结构定义了openEHR系统中使用的所有标识符类型。这些中的大多数具有多部分结构，并且一些是“有意义的”，即人类可读的。标识符类型可以用于表示在语义上分为两组的标识符值：由openEHR（其可以包括通用标准标识符，例如ISO Oids等）定义的标识符值和由外部组织定义的那些。组如下表所示。标识符的形式由HIEROBJECT_ID类型定义，由openEHR和许多其他组织使用。

抽象类型UIDBASEDID及其两个子类型HIEROBJECTID和OBJECTVERSIONID分别提供未版本化和版本化项目的基于UID的标识符。后者子类型的设计在openEHR Common IM，change_control包中进行了说明。

原型标识符

ARCHETYPE_ID子类型定义原型的多轴标识符，意味着每个标识符实例表示多维空间中的单个原型。空间可以被认为是3维的，或者作为版本化的2维空间，由以下轴组成：

- 参考模型实体，即原型的目标，定义为：

    - 模型发行人名称;

    - 模型名称（可能有多个来自同一个发行者）;

    - 模型中的概念名称，即类名称

- 领域概念;

- 版。

三个外部部分由“。”分隔。字符，而第一部分的部分由“ - ”字符分隔。与任何多轴标识符一样，原型标识符的基本原理是标识符的所有部分必须能够被认为是不可变的。这意味着，其标识符中不能包括原型的可变特征（例如，认证机构，其可能由于另一机构稍后的认证而改变，或者可以是多个）。明确包含版本作为标识符的一部分意味着原型的两个“版本”实际上是两个不同的原型。 （原型版本，修订版本和其他变体的规则在openEHR原型标识规范[openehramidentification]中给出。）

原型标识符的示例包括：

• openEHR-EHR-SECTION.physical_examination.v2

• openEHR-EHR-SECTION.physical_examination-prenatal.v1

• H17-RIM-Act.progress_note.v1

• openEHR-EHR-OBSERVATION.progress_note-naturopathy.v2

原型标识符的语法在下面[原型ID语法]中给出。

警告：一些原型创作工具历史上允许在原型标识符中包括生命周期状态的不合格版本部分。这导致一些原型具有其版本部分具有“.v1draft”或类似形式的标识符。 openHHR基金会将在其网站上公布处理这个问题的指南和时间表。新的和现有的原型工具可能必须支持此异常，这取决于它们将被使用的位置，并且建议至少通过命令行开关或选项来支持它。在这种不合格的原型在新环境中重新使用的情况下，应当校正该标识符。

模板标识符

模板标识符在意图上类似于类型标识符 - 除了可以使用的任何UID样式的标识符之外，它提供了多轴可读的标识符。在此版本中，尚未定义确切的结构，但当前的提议如下：

• 创作组织反向域名;

• 模板化的参考模型类的标识符;

• 逻辑名称模板;

• 版本标识符，形式为“vn”，其中n是数字版本标识符。

这将导致如下的标识符：

• uk.nhs.cfh：openehr-EHR-COMPOSITION.admission_ed.v5

在未来的版本中将描述一个固定形式的模板标识符。 术语标识符

TERMINOLOGY_ID子类型定义术语的全局唯一单字符串标识符。术语标识符值可以包括版本，或者作为名称的一部分，和/或根据下面4.3.12节中定义的语法。术语标识符的示例包括：

• “SNOMED-CT”

• “ICD9（1999）”

目前，标识符名称部分（即，括号中不包括可选版本部分的部分）的最佳权威来源是美国国家医学图书馆包含术语的UMLS标识符 - 请参见http://www.nlm.nih.gov/ research / umls / metaa1.html。

由TERMINOLOGY_ID类定义的方案提供了诸如世界卫生组织的“ICD10”和“ICD10AM”（AM =“澳大利亚修改”）等术语的主要“版本”可以容纳更精细的版本或修订版本的情况，例如：

• “ICD10AM（3rd_ed）”

• “ICD10AM（4th_ed）”

术语标识符的版本部分在理论上对于那些破坏了用代码标识的概念丢失或改变其对术语版本的含义的规则的那些术语绝对必要。这不适用于现代术语和本体，特别是那些从Cimino的“desiderata”[Doc No：]出版之后设计的术语和本体，其中“概念永久性”的原则在这里适用 - “概念的意义不能改变，从词汇表中删除“。然而，可能存在较旧的术语，或可能不遵守这些规则但仍然使用的专门术语;版本ID应始终用于这些。在实践层面，在一些系统中可以常规地包括版本以支持潜在的医学法律需要，以证明a）给定代码事实上在术语中定义（它可能在早期版本中不存在），以及b）在系统中所赋予的意义确实是在特定版本或版本中赋予它的意思。

等价

尽管在一些已公布的术语中以及在相同术语的一些版本之间存在异常，但是忽略版本部分的两个相同的术语标识符通常可以被认为是术语世界中的语义等同物。然而，取决于为标识符的名称部分选择了哪个字符串源，两个不同的标识符也可以指示相同的术语，例如， “ICD10AM2000”（在UMLS中使用的NLM标识符）和“ICD10AM（2nded）”是指相同的东西。 在openEHR版本化容器内标识版本

OBJECTVERSIONID定义了在openEHR中用于标识版本化容器中版本的方案的语义，并使用由三部分组成的标识符，包括：

• object_id：版本容器的标识符，以UID的形式;

• versiontreeid：版本树中的位置，作为1或3部分数字标识符，其中后一个变体表示分支;这是使用VERSIONTREEID类型建模的;

• creationsystemid：创建此版本的系统的标识符，或键入UID。

在该方案下，同一容器中的多个版本都具有相同的object_id值，而它们在版本树中的位置由版本树标识符和创建系统的标识符的组合给出。

对标识符第三部分的要求是它对于每个系统是唯一的，并且容易获得或生成。如果它是有意义的标识符也是有帮助的。两个最实用的候选者似乎是GUID（它们没有意义，但容易生成）和反向互联网域标识符，如[3]中所建议的（这些很容易确定系统是否有互联网地址，并且有意义并且可直接处理，然而未连接的系统引起问题）。也可以使用ISO Oids。所有这些标识符类型通过使用UID来容纳。版本标识方案及其功能的完整解释在Common IM的change_control部分中给出。 通用和外部标识符

GENERIC_ID类型提供了除rm.support.identification包中具体定义的方案的标识符。它具有单个方法方案，其可以用于记录标识符类型。方案的名称当前未受控制。 分层标识符

HIEROBJECTID类型被定义为支持分层标识符，通常基于ISO Oids或其他类似的机器可读和可解析方案。

复合标识符和案例

所有复合标识符应遵循两种规则，即：

• 保持案例 - 不因持久性，复制，传输或其他计算过程而发生变化;

• 为不区分大小写的 - 除了情况之外的两个标识符被认为是相同的，并且因此标识相同的事物。

这些规则的实际后果如下：

• 可以使用混合大小写的标识符，例如原型标识符，混合大小写的反向域标识符（INTERNET_ID类型）;

• 在公开的EHR系统内创建的标识符的字母中选择的原始案例应由相关发布组织发布（例如，NLM UMLS术语名称均为大写）;

• 如果标识符用作计算机文件系统中的文件名的一部分，则必须注意正确地创建和保留文件名。因此，软件通常必须在Unix风格的操作系统上处理文件名创建和修改，这些操作系统区分大小写（因此区分大小写），而Windows风格的操作系统不区分大小写，保存。

这些规则不适用于以语言不存在的语言构建的任何标识符作为概念。因此，对于翻译成土耳其语的标识符（可能还有较小的相关语言），必须注意“I / i”字符。

复合标识符和语言

在上面所有的“有意义”标识符类型中，使用可见的异常GENERIC_ID，人类可读的标识符部分被假定为只使用基本的拉丁字符集，可能添加了生产规则所允许的其他特殊字符下面为每个标识符。在大多数情况下，这些标识符的文本部分将是来自英语的单词，否则它们将是来自其他语言的可识别单词，必要时可以引用到拉丁字母表中。不允许使用重音和其他变音字母变体。这种限制是出于实际标识符可计算性的目的，并且与标准世界中的共享UML模型中的类和属性命名以及互联网域名和因特网URI一样。

4.2.3.参考文献

所有OBJECTID用作它们标识的事物内的标识符属性，与数据库主键相同。要引用来自另一个对象的标识对象，通常应该使用类OBJECTREF的实例，与数据库外键相同。类OBJECT_REF作为分布式引用的一种手段提供，并且包括对象名称空间（通常为1：1，带有某些服务，例如“术语”）和类型。对象引用的一般原则是能够引用特定命名空间或服务中可用的对象。通常，它们用于指代其他服务中的对象，例如来自EHR内的人口统计实体，但是它们也可以用于指代本地对象。类型可以是被引用对象（例如“GP”）或任何适当的祖先（例如PARTY）的具体类型。

4.3.类描述

4.3.1. UID类

4.3.2. ISO_OID类

4.3.3. UUID类

4.3.4. INTERNET_ID类

4.3.5. OBJECT_ID类

信息对象的标识符的祖先类。 Id可能是完全无意义的，在这种情况下，他们唯一的工作是引用某物，或者可能携带与所识别的对象有关的一些信息。

对象ID在对象内部用于标识该对象。要标识另一个服务中的另一个对象，请使用OBJECT_REF，否则对由UID标识的本地对象使用UID。如果没有一个子类型是合适的，则可以使用该类的直接实例。

4.3.6. UIDBASEDID类

4.3.7. HIEROBJECTID类

4.3.8. OBJECTVERSIONID类

版本化对象的一个​​版本的全局唯一标识符;词法形式：object_id ::'creation_system_id ::'version_tree_id

4.3.9. VERSIONTREEID类

一个版本的版本树标识符。词汇形式：

trunk_version ['。 branch_number'。 branch_version]

4.3.10. ARCHETYPE_ID类

4.3.11. TEMPLATE_ID类

4.3.12. TERMINOLOGY_ID类

例如通过术语查询服务访问的术语的标识符。在此类中，value属性标识术语服务中的术语，例如。 SNOMED-CT。术语假定为特定语言，必须明确指定。

如果id属性是精确术语id标识符，包括实际版本（即实际版本），本地修改等的值;例如ICPC2.

词汇形式：name [（'version）']

4.3.13. GENERIC_ID类

4.3.14. OBJECT_REF类

4.3.15. ACCESSGROUPREF类

4.3.16. PARTY_REF类

4.3.17. LOCATABLE_REF类

4.4.语法

上面定义的标识符通过以下EBNF语法规则以其字符串形式定义。

（* --------------------------- INTERNET_ID -------------------- ------- *）
（*根据IETF http://tools.ietf.org/html/rfc1034[RFC 1034]和*）
（* http://tools.ietf.org/html/rfc1035[RFC 1035]，由*表示）
（* http://tools.ietf.org/html/rfc2181 [RFC 2181]（第11节），*）
（*域名的语法遵循语法：*）

domain = subdomain | '';
subdomain = label | subdomain，'。'，label;
label = letter [[ldh-str] let-dig];
ldh-str = let-dig-hyp | let-dig-hyp，ldh-str
let-dig-hyp = let-dig | ' - ';
let-dig = letter |数字 ;

（* --------------------------- INTERNET_ID -------------------- ------- *）
internet_id = root ['::'extension];
root = uid;
extension =？任何字符串？ ; （*任何字符串*）

（* ------------------------- OBJECT_VERSION_ID ---------------------- - *）
object_version_id = object_id'::'creation_system_id'::'version_tree_id;
object_id = uid;
creation_system_id = uid;

（* ------------------------- VERSION_TREE_ID ---------------------- --- *）
version_tree_id = trunk_version ['。' branch_number'。 branch_version];
trunk_version = number;
branch_number = number;
branch_version = number;

（* ------------------------- UID，OID，GUID ------------------ -------- *）
uid = iso_oid | guid;
iso_oid = number，{'。'，number};
guid =十六进制数，' - '，十六进制数，' - '，十六进制数，' - '，十六进制数，

（* -------------------------- ARCHETYPE_ID --------------------- ------ *）
archetype_id = qualified_rm_entity'。' domain_concept'。' version_id;
qualified-rm-entity = rm_originator' - 'rm_name' - 'rm_entity;
rm-originator = alphanum-str; （* id，源自此原型所基于的RM的org *）
rm-name = alphanum-str; （*原型所基于的RM的* id *）
rm-entity = alphanum-str; （* RM *中的本体级）
domain-concept = concept-name {' - 'specialization};
concept-name = alphanum-str;
specialization = alphanum-str
version-id ='v'，non-zero-digit，[number]; （*数字版本标识符*）

（* ------------------------- TERMINOLOGY_ID ---------------------- ---- *）
terminology_id = name-str，['（'，name-str，'）'];

（* --------------------------一般规则-------------------- ------ *）
name-str = letter，{letter |数字| '_'| ' - '| '/'| '+'};
alphanum-str = letter，{letter |数字| '_'};
letter ='a'| .. | 'z'| 'A'| .. | 'Z';

number = digit，{digit};
hex-number =十六进制数，{hex-digit};
digit ='0'| nz_digit;
非零数字='1'| .. | '9';
hex-digit ='0'| .. | 'A'| .. | 'F'.. | 'a'| .. | 'F' ;

5.术语包

5.1.概述

本节介绍术语包，其中包含用于访问术语和代码集的类，包括openEHR支持术语，来自参考模型中定义的类的实例。这里显示的类通常通过类EXTERNALENVIRONMENTACCESS和OPENEHR_DEFINITIONS继承，尽管如何完成的确切细节可能会因实现语言而异。

5.2.服务接口

5.2.1.代码集

根据图6定义了简单的术语服务接口，使得能够从参考模型中正式引用openEHR代码集和术语。在openEHR中区分两种类型的编码实体，并且可以通过服务接口访问。第一个是来自“代码集”的代码，这是代码代表其自身的术语，例如ISO 639-1语言代码。这些代码集的标识符本身似乎不是标准化的，但是希望使用诸如“ISO_639-1”的名称（见下文）。

在任何情况下，openEHR模型本身（例如对于其值是语言代码的属性）中所需的代码集不直接由诸如“ISO639-1”的外部名称引用，而是通过内部常量，在这种情况下，常量Codesetidlanguages，其值被定义为“语言”。这些常量在UML图中的OPENEHRCODESETIDENTIFIERS类中定义。内部标识符和外部名称之间的映射应在配置文件中完成。服务函数TERMINOLOGYSERVICE.code_setforid（）用于在常数的基础上检索代码集。 openEHR中假定的当前映射和外部标识符在openEHR支持术语文档中定义。使用间接的这种使用以确保代码集的过时和取代不直接影响openEHR软件。

对于未映射到内部使用的常量的代码集，即openEHR模型本身不需要但在术语服务中已知的代码集，函数TERMINOLOGYSERVICE.codeset（）可以用于通过其外部标识符检索这些代码集。

5.2.2.术语

包括openEHR支持术语的术语通过TERMINOLOGYSERVICE函数术语（）和terminologyidentifiers（）访问，其中参数包括“openehr”，“centc251”（对于CEN TC / 251代码）和来自美国NLM术语表的名称）。 openEHR术语支持组，参考模型所需的组的集合在类OPENEHR_TERMINOLOGYGROUPIDENTIFIERS中定义。这些组对应于在openEHR参考模型中找到的编码属性。

5.2.3. openEHR参考模型中的条款和代码

参考模型中的真编码属性（即类型DVCODEDTEXT的属性），例如FEEDERAUDIT.changetype由封闭类中的不变量定义，例如以下：

Changetypevalid：术语（Terminologyidopenehr）.hascodeforgroupid （Groupidauditchangetype，changetype.definingcode）

这是一种形式化的方式，称属性changetype必须具有一个值，使得其definecode（其CODEPHRASE）在openEHR术语中的CODEPHRASE的集合中，该集合在其标识符为Groupidauditchangetype的组中。

类似的不变量用于类型CODEPHRASE的属性，它来自codeset。以下不变式出现在ENTRY类（rm.composition.content.entry包）中：

Languagevalid：mediatype / = Void然后codeset（Codesetlanguages）.hascode（language）

5.3.身份标识

在openEHR中，术语或代码集的标识符在类CODEPHRASE（数据类型信息模型，文本包）的terminologyid属性中找到。 5.3.1.代码集标识符

在openEHR中使用的内部代码集标识符（例如“语言”）在类OPENEHRCODESETIDENTIFIERS中定义; openEHR参考模型使用的代码集的假定外部标识符（例如“ISO639-1”）在openEHR支持术语文档中定义。

5.3.2.术语标识符

可用于此属性的术语的有效标识符包括但不限于以下内容：

• “openehr”

• “centc251”

• 来自美国国家图书馆或医学（NLM）UMLS术语标识符表的第一列的标识符值，以两种形式中的任一种：

  • 例如， “ICD10AM_2000”，“ICPC93”;

  • 除去以下划线开始的任何尾部分，例如。 “ICD10AM”。

在一些标准中使用其他标识方案，例如ISO Oids。这些不是直接用于openEHR由于各种原因：

• 它们当前不被NLM使用，并且没有可用的明确公布的术语标识符列表;

• ISO Oids是长标识符，并且可能由于编码项的普遍性而显着增加持久信息的大小;

• 确定数据中的术语的身份总是需要对包含Oid /名称映射的服务的请求;

• 在数据中具有人可读术语标识符的安全因素。

然而，基于Oid或其他术语识别方案的使用与openEHR不兼容;所需要的是术语标识符/名称映射服务或表。

下表是美国国家医学图书馆UMLS术语标识符列表的快照。最新的最新列表可以在NLM网站[NLMUMLlist]上找到。

5.4.类定义

5.4.1. TERMINOLOGY_SERVICE类

code_set（name：String）：CODE_SET_ACCESS
前缀：has_code_set（name）

code_set_for_id（id：String）：CODE_SET_ACCESS
前：valid_code_set_id（id）

如果此服务已知名为名称的术语，则为true。允许的名称包括： - * openehr * centc251 *任何名称取自美国NLM UMLS元数据列表，网址为http://www.nlm.nih.gov/research/umls/metaa1.html

术语服务中已知的所有术语标识符集。美国NLM UMLS元数据列表中的值： - http://www.nlm.nih.gov/research/umls/metaa1.html

5.4.2. TERMINOLOGY_ACCESS接口

5.4.3. CODESETACCESS接口

5.4.4. OPENEHRTERMINOLOGYGROUP_IDENTIFIERS类

5.4.5. OPENEHRCODESET_IDENTIFIERS类

6.测量包

6.1.概述

测量包定义了与定量测量，单位和转换相关的最小语义，使得能够正确表达openEHR数据类型信息模型的Quantity包。对于术语包，假设一个简单的服务接口，它为参考模型的其他部分提供有用的功能。测量和单位的定义来自各种来源，包括：

• CEN ENV 12435，医学信息学 - 健康科学测量结果的表达（见http://www.centc251.org）;

• 由Gunther Schadow和Clement J.McDonald of The Regenstrief Institute（可在HL7v3投票材料中获得; http://www.hl7.org）开发的统一测量单位代码（UCUM）。

这些当然依赖于大量的文献和标准，主要来自ISO关于科学测量的主题。

• 6.2.服务接口

根据下图定义简单的测量数据服务接口，使得定量语义能够在参考模型内正式使用。注意，目前定义的这个服务没有寻求对单元，转换等的语义进行正确的建模 - 它只提供openEHR参考模型所需的最小函数。

6.3.类定义

6.3.1. TERMINOLOGY_SERVICE类

code_set（name：String）：CODE_SET_ACCESS
前缀：has_code_set（name）

code_set_for_id（id：String）：CODE_SET_ACCESS
前：valid_code_set_id（id）

7.定义包

7.1.概述

定义包定义了openEHR模型使用的符号定义。当前仅定义了少量数字。

7.2.类定义

7.2.1. OPENEHR_DEFINITIONS类

7.2.2. BASIC_DEFINITIONS类

参考文献

出版物

1. [Anderson_1996]罗斯·安德森。临床信息系统的安全性。可在http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html获得。
2. [Baretto_2005] Barretto S A.设计基于指南的工作流程 - 综合电子健康记录。南澳大学博士论文。可在http://www.cis.unisa.edu.au/~cissab/Barretto_PhD_Thesis_Revised_FINAL.pdf。
3. [Beale_2000] Beale T. Archetypes：Constraint-based Domain Models for Future-proof Information Systems。 2000.可查阅http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_web_2000.pdf。
4. [Beale_2002] Beale T.Archetypes：Constraint-based Domain Models for Future-proof Information Systems。第十一届OOPSLA行为语义研讨会：为客户服务（西雅图，美国华盛顿，2002年11月4日）。由Kenneth Baclawski和Haim Kilov编辑。 Northeastern University，Boston，2002，pp。16-32.请访问http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_oopsla_2002.pdf。
5. [Beale_Heard_2007] Beale T，Heard S. An Ontology-based Model of Clinical Information。 2007.pp760-764 Proceedings MedInfo 2007，K.Kuhn et al。 （Eds），IOS Publishing 2007.见http://www.openehr.org/publications/health_ict/MedInfo2007-BealeHeard.pdf。
6. [Booch_1994] Booch G.面向对象的分析和设计与应用。第2版​​。本杰明/ Cummings 1994.
7. [Browne_2005] Browne E D.工作流建模协调的健康护理提供者护理计划。南澳大学博士论文。请访问http://www.openehr.org/publications/workflow/t_browne_thesis_abstract.htm。
8. [Cimino_1997] Cimino J J. Desiderata for Controlled Medical vocabularies in the Twenty-F​​irst Century。 IMIA WG6 Conference，Jacksonville，Florida，Jan 19-22,1997.
9. [埃菲尔]迈耶B.埃菲尔的语言（第二版）。 Prentice Hall，1992.
10. [Elstein_1987] Elstein AS，Shulman LS，Sprafka SA。医学问题解决：临床推理的分析。剑桥，MA：哈佛大学出版社1987.
11. [Elstein_Schwarz_2002] Elstein AS，Schwarz A.临床诊断的证据基础：临床问题解决和诊断决策：对认知文献的选择性审查。 BMJ 2002; 324; 729-732.
12. [Fowler_1997] Fowler M.分析模式：可重用对象模型。 Addison Wesley 1997
13. [Fowler_Scott_2000] Fowler M，Scott K.UML Distilled（2nd Ed。）。 Addison Wesley Longman 2000.
14. [Gray_reuter_1993] Gray J，Reuter A. Transaction Processing Concepts and Techniques。 Morgan Kaufmann 1993.
15. [Hein_2002] Hein J L.Discrete Structures，Logic and Computability（2nd Ed）。琼斯和巴特利特2002.
16. [Hnìtynka_2004]HnìtynkaP，PlášilF. MOF的分布式版本控制模型。 Proceedings of WISICT 2004，Cancun，Mexico，A volume in the ACM international conference proceedings series，published by Computer Science Press，Trinity College Dublin Ireland，2004.
17. [Ingram_1995] Ingram D.欧洲良好健康记录项目。 Laires，Laderia Christensen，Eds。健康在新的通信时代。阿姆斯特丹：IOS出版社; 1995; pp。66-74.
18. [Kifer_Lausen_Wu_1995] Kifer M，Lausen G，Wu J. Logical Foundations of Object-Oriented and FrameBased Languages。 JACM 1995年5月。见见ftp://ftp.cs.sunysb.edu/pub/TechReports/kifer/flogic.pdf。
19. [Kilov_1994] Kilov H，Ross J.信息建模 - 面向对象的方法。 Prentice Hall 1994.
20. [Maier_2000] Maier M.系统建模原则。技术报告，阿拉巴马大学在亨茨维尔。 2000.可在http://www.infoed.com/Open/PAPERS/systems.htm获得
21. [Martin] Martin P. UML，OWL，KIF和WebKB-2语言之间的翻译（For-Taxonomy，Frame-CG，Formalized English）。 May / June 2003. Available at http://www.webkb.org/doc/model/comparisons.html as at Aug 2004.
22. [Meyer_OOSC2] Meyer B. Object-oriented Software Construction，2nd Ed。 Prentice Hall 1997
23. [Müller_2003]MüllerR. Event-oriented Dnamic Adaptation of Workflows：Model，Architecture，and Implementation。莱比锡大学博士论文。请访问http://www.openehr.org/publications/workflow/t_mueller_thesis_abstract.htm。
24. [Object_Z] Smith G.对象Z规范语言。 Kluwer Academic Publishers 2000.见http://www.itee.uq.edu.au/~smith/objectz.html。
25. [Rector_1994] Rector A L，Nowlan W A，Kay S. Foundations for an Electronic Medical Record。 The IMIA Yearbook of Medical Informatics 1992（Eds.van Bemmel J，McRay A）。 Stuttgart Schattauer 1994.
26. [Rector] Rector A L.临床术语：为什么这么难？方法。 1999 Dec; 38（4-5）：239-52.可在http://www.cs.man.ac.uk/~rector/papers/Why-is-terminology-hard-single-r2.pdf。
27. [Richards_1998] Richards E G. Mapping Time - The Calendar and its History。牛津大学出版社1998.
28. [Sowa_2000] Sowa J F.知识表示：逻辑，哲学和计算基础。 2000，Brooks / Cole，California。
29. [Sottile_1999] Sottile P.A.，Ferrara F.M.，Grimson W.，Kalra D.，and Scherrer J.R.The holistic healthcare information system。欧洲电子健康记录。 1999年11月; 259-266.
30. [Van_de_Velde_Degoulet_2003] Van de Velde R，Degoulet P. Clinical Information Systems：A Component-Based Approach。 2003. Springer-Verlag New York。
31. [Weed_1969] Weed LL。医疗记录，医疗教育和病人护理。 6 ed。芝加哥：年鉴医疗出版商公司1969年。

资源

本体

1. [bfo]正式本体和医学信息科学研究所（IFOMIS）。基本正式本体论（BFO）。 http://ifomis.uni-saarland.de/bfo/。
2. [FMA] http://sig.biostr.washington.edu/projects/fm/。
3. [Horrocks_owl] Patel-Schneider P，Horrocks I，Hayes P. OWL Web本体语言语义和抽象语法。请参阅http://w3c.org/TR/owl-semantics/。
4. 信息工件本体。 https://code.google.com/p/information-artifact-ontology/。
5. [OBO] The Open Biological and Biomedical Ontologies。见http://www.obofoundry.org/。
6. [OGMS]一般医学科学本体（OGMS）。 https://code.google.com/p/ogms/。

一般

1. [covcontra]维基百科。协方差和逆变。请参阅https://en.wikipedia.org/wiki/Covarianceand_contravariance(computerscience）。

电子卫生标准

1. [ENV13606-1] ENV 13606-1 - 电子医疗记录通信 - 第1部分：扩展架构。 CEN / TC 251健康信息技术委员会。
2. [ENV13606-2] ENV 13606-2 - 电子医疗记录通信 - 第2部分：域名术语列表。 CEN / TC 251健康信息技术委员会。
3. [ENV13606-3] ENV 13606-3 - 电子医疗记录通信 - 第3部分：分发规则。 CEN / TC 251健康信息技术委员会。
4. [ENV13606-4] ENV 13606-4 - 电子医疗记录通信标准第4部分：信息交换的信息。 CEN / TC 251健康信息技术委员会。
5. [CorbamedPIDS]对象管理组。人身份识别服务。 1999年3月。
6. [CorbamedLQS]对象管理组。词典查询服务。 1999年3月。
7. [HL7v3ballot2] JL7国际。 HL7版本3第二选票规格。可在http://www.hl7.org获得。
8. [HL7v3datatypes] Schadow G，Biron P. HL7版本3可交付：版本3数据类型。 （2002年第二版投票）。
9. [hl7v3rim] HL7. HL7 v3 RIM。见http://www.hl7.org。
10. [ICD10AM]。世卫组织/ ACCD。国际疾病分类，第10次修订，澳大利亚修改。请参见https://www.accd.net.au/Icd10.aspx
11. [IHTSDO]国际健康术语标准制定组织（IHTSDO）。 http://www.ihtsdo.org。
12. [IHTSDOURIs] IHTSDO。 SNOMED CT URI标准。 http://ihtsdo.org/fileadmin/userupload/doc/download/docUriStandardCurrent-en-USINT20140527.pdf?ok。
13. [NLMUMLlist]国家医学图书馆。 UMLS术语表。 http://www.nlm.nih.gov/research/umls/metaa1.html。
14. [SNOMEDCT] IHTSDO。系统化命名医学。请参见http://www.ohtsdo.org。
15. [WHOICD]世界卫生组织（WHO）。国际疾病分类（ICD）。见：http：//www.who.int/classifications/icd/en/。
16. [ISO18308] Schloeffel P.（编辑）。电子健康记录参考架构的要求。 （ISO TC 215 / SC N; ISO / WD 18308）。国际标准组织，澳大利亚，2002年。
17. [ISO20514] ISO。综合护理EHR。见http://www.iso.org/iso/isocatalogue/cataloguetc/cataloguedetail.htm?csnumber=39525.
18. [UCUM] Schadow G，McDonald C J.The Unified Code for Units of Measure，Version 1.4 2000.Regenstrief Institute for Health Care，Indianapolis。请参阅http://aurora.rg.iupui.edu/UCUM

电子卫生项目

1. [CIMI]临床信息建模倡议（CIMI）项目。参见http://opencimi.org。
2. [EHCR_supA_14] Dixon R，Grubb P A，Lloyd D，and Kalra D. Consolidated List of Requirements。 EHCR支持行动交付1.4.欧洲委员会DGXIII，布鲁塞尔; 2001年5月59pp可从http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v1_3.PDF获得。
3. [EHCR_supA_35] Dixon R，Grubb P，Lloyd D. EHCR支持行动交付3.5：“对CEN未来工作的最终建议”。 2000年10月。见http://www.chime.ucl.ac.uk/HealthI/EHCRSupA/documents.htm。
4. [EHCR_supA_24] Dixon R，Grubb P，Lloyd D. EHCR支持行动2.4“CEN EHCRA解释和实施指南”。 2000年10月。见http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm。
5. [Lloyd D，et al。 EHCR支持行动交付3.1和3.2“CEN的中期报告”。 July 1998. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm。
6. [GEHR_del_4]可交付成果4：GEHR临床综合性要求。 GEHR项目1992
7. [GEHR_del_7]可交付成果7：临床功能规范。 GEHR项目1993
8. [GEHR_del_8]可交付成果8：GEHR架构和系统的伦理和法律要求。 1994年GEHR项目
9. [GEHR_del_19_20_24]交付成果19,20,24：GEHR架构。 GEHR项目30/6/1995
10. [GeHR_AUS] Heard S，Beale T.The Good Electronic Health Record（GeHR）（Australia）。请参阅http://www.openehr.org/resources/related_projects#gehraus。
11. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia，GPCG Trial。可在http://www.gehr.org/gpcg/ehra.htm。
12. [GeHR_Aus_req] Beale T，Heard S.GEHR技术要求。请参阅http://www.gehr.org/technical/requirements/gehr_requirements.html。
13. [Synapses_req_A] Kalra D.（Editor）。突触用户需求和功能规范（A部分）。欧盟远程信息处理应用程序，布鲁塞尔; 1996;突触项目：可交付用户1.1.1a。 6章，176页。
14. [Synapses_req_B] Grimson W.和Groth T.（Editors）。突触用户需求和功能规范（B部分）。欧盟远程信息处理应用程序，布鲁塞尔; 1996;突触项目：可交付用户1.1.1b。
15. [Synapses_odp] Kalra D.（编辑）。突触ODP信息观点。欧盟远程信息处理应用程序，布鲁塞尔; 1998;突触项目：最终交付。 10章，64页。
16. [synex]伦敦大学学院。 SynEx项目。 http://www.chime.ucl.ac.uk/HealthI/SynEx/。

一般标准

1. [OCL]对象约束语言2.0.对象管理组（OMG）。可在http://www.omg.org/cgi-bin/doc?ptc/2003-10-14.
2. [IANA] IANA。 http：//www.iana.org/。
3. [IEEE_828] IEEE。 IEEE 828-2005：软件配置管理计划标准。
4. [ISO_8601] ISO 8601标准描述了表示时间，日期和持续时间的格式。参见例如http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html和http://www.cl.cam.ac.uk/~mgk25/iso-time.html 。
5. [ISO_2788] ISO。 ISO 2788单语词典的建立和发展指南。
6. [ISO_5964] ISO。 ISO 5964建立和开发多语言词典的指南。
7. [Perl_regex] Perl.org。 Perl正则表达式。可在http://perldoc.perl.org/perlre.html。
8. 斯坦福大学。参见http://protege.stanford.edu/。
9. [rfc_2396] Berners-Lee T.Universal Resource Identifiers in WWW。可在http://www.ietf.org/rfc/rfc2396.txt。这是一个用于全局资源识别的万维网RFC。在当前在网上使用时，由Mosaic，Netscape和类似工具。有关URI的起点，请参阅http://www.w3.org/Addressing。
10. [rfc_2440] RFC 2440：OpenPGP消息格式。见http://www.ietf.org/rfc/rfc2440.txt和http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt
11. [rfc_3986] RFC 3986：统一资源标识符（URI）：通用语法。 IETF。参见http://www.ietf.org/rfc/rfc3986.txt。
12. [rfc_4122] RFC 4122：通用唯一标识符（UUID）URN命名空间。 IETF。参见http://www.ietf.org/rfc/rfc4122.txt。
13. [rfc_2781] IETF。 RFC 2781：UTF-16，ISO 10646的编码见http://tools.ietf.org/html/rfc2781.
14. [rfc_5646] IETF。 RFC 5646. Available at http://tools.ietf.org/html/rfc5646.
15. [sem_ver]语义版本化。 http://semver.org。
16. [Xpath] W3C Xpath 1.0规范。 1999.可在http://www.w3.org/TR/xpath。
17. [uri_syntax]统一资源标识符（URI）：通用语法，因特网提议的标准。 2005年1月。见http://www.ietf.org/rfc/rfc3986.txt。
18. [w3c_owl] W3C。 OWL - Web本体语言。请参阅http://www.w3.org/TR/2003/CR-owl-ref-20030818/。
19. [w3c_xpath] W3C。 XML路径语言。请参阅http://w3c.org/TR/xpath。

工具

1. [Template_Designer]模板设计器。海洋信息学。 http://www.openehr.org/downloads/modellingtools。

openEHR资源

1. [openehr_18308] openEHR基金会。 openEHR架构符合ISO TS 18308“EHR体系结构的要求”。请参阅http://www.openehr.org/releases/trunk/architecture/iso18308_conformance.pdf。
2. [openEHR_ADL_workbench] openEHR基金会。 openEHR ADL工作台。 http://www.openehr.org/downloads/ADLworkbench/home。
3. [openehr_am_overview] openEHR基金会。 openEHR原型技术概述。请参阅http://www.openehr.org/releases/AM/latest/Overview.html。
4. [openehr_am_adl14] openEHR基金会。原型定义语言1.4（ADL1.4）。请访问http://www.openehr.org/releases/AM/latest/ADL1.4.html。
5. [openehr_am_aom14] openEHR基金会。原型对象模型1.4（AOM1.4）。请访问http://www.openehr.org/releases/AM/latest/AOM1.4.html。
6. [openehr_am_adl2] openEHR基金会。原型定义语言2（ADL2）。请访问http://www.openehr.org/releases/AM/latest/ADL2.html。
7. [openehr_am_aom2] openEHR基金会。原型对象模型2（AOM2）。请访问http://www.openehr.org/releases/AM/latest/AOM2.html。
8. [openehr_am_identification] OpenEHR基金会。原型标识规范。请访问http://www.openehr.org/releases/AM/latest/Identification.html。
9. [openehr_am_def_pri] openEHR基金会。原型定义和原则。 （已弃用）可查阅http://www.openehr.org/releases/1.0.2/architecture/am/archetype_principles.pdf。
10. [openehr_am_sys] openEHR基金会。原型系统。 （已弃用）可查阅http://www.openehr.org/releases/1.0.2/architecture/am/archetype_system.pdf。
11. [openehr_am_oap] openEHR基金会。 openEHR原型配置文件。 http://www.openehr.org/releases/1.0.2/architecture/am/openehr_archetype_profile.pdf。
12. [openehr_CKM] openEHR临床知识经理（CKM）。请参阅http://www.openEHR.org/ckm
13. [openehr_odin] openEHR基金会。对象数据实例符号（ODIN）。请访问http://www.openehr.org/releases/BASE/latest/odin.html。
14. [openeneH_overview] openEHR基金会。 openEHR架构概述。请参阅http://www.openehr.org/releases/BASE/latest/architecture_overview.html。
15. [openehr_query_aql] openEHR基金会。 openEHR原型查询语言（AQL）。请参阅http://www.openehr.org/releases/QUERY/latest/AQL.html。
16. [openehr_rm_data_types] openEHR。数据类型信息模型。请参阅http://www.openehr.org/releases/RM/Release-1.0.3/data_types.html。
17. [openehr_rm_data_structures] openEHR。数据结构信息模型。请参阅http://www.openehr.org/releases/RM/Release-1.0.3/data_structures.html。
18. [openehr_rm_common] openEHR。公共信息模型。请参阅http://www.openehr.org/releases/RM/Release-1.0.3/common.html。
19. [openehr_rm_ehr] openEHR基金会。 EHR信息模型。 http://www.openehr.org/releases/RM/Release-1.0.3/ehr.html。
20. [openehr_rm_ehr_extract] openEHR基金会。 EHR Extrct信息模型。 http://www.openehr.org/releases/RM/Release-1.0.3/ehr_extract.html。
21. [openehr_rm_integration] openEHR基金会。集成信息模型。 http://www.openehr.org/releases/RM/Release-1.0.3/integration.html。
22. [openehr_rm_support] openEHR。支持信息模型。请参阅http://www.openehr.org/releases/RM/Release-1.0.3/support.html。
23. openEHR基金会。 openEHR术语http://www.openehr.org/releases/TERM/latest/SupportTerminology.html。
24. [openeneHL基金会]。 openEHR术语项目（GitHub）https://github.com/openEHR/terminology。

最后更新2015-12-10 13:17:53 GMT