资源定义 - FHIR DSTU 1 (v0.0.82)
目录
1.12.0 资源定义
本技术规范定义的是一系列不同类型的，可用于交换和/或存储数据的资源，以便解决临床和管理两个方面种类多样的医疗保健相关问题。此外，本技术规范还定义了几种用于交换这些资源的不同方式。
资源指的是具有下列特点的实体：
- 具有一个已知的，可用于对其加以寻址的标识（URL）
- 将其自身标识为本技术规范所定义的资源类型之一
- 含有一套相应资源类型的定义所描述的结构化数据项
- 含有资源内容的人工可读型XHTML表达形式
- 具有一个经过标识的版本，且版本会随着资源内容的变更而变更
资源具有多种表达形式。如果其满足上述规则，那就是有效的资源，并且，可以依据本技术规范之中所定义的规则，采用XML或JSON来加以表达。另外，亦可采取其他的表达形式，但本技术规范并未对它们加以描述。
1.12.0.0.1 定义
本页面的基本定义：
| 资源 Resource | 所存储或交换的数据实例 |
| 资源定义 Resource Definition | 定义的是组成资源的那些数据元 |
| 概貌/集成规范 Profile | 关于特定应用语境下数据元的附加规则。有一种特殊类型的资源——那就是概貌资源Profile。 |
1.12.0.1 资源内容
All types of resources have the following optional or mandatory elements and properties: 所有类型的资源都具有下列可选型或必备型元素和属性：
- 相应类型所特有的，基本的一套经过定义的数据元
- 扩展（extensions）：实施项目所额外新增的数据元
- 对于资源内容的人工可读性叙述（human-readable narrative）型描述
- 被包含型资源（contained resources）：作为相应资源标识与交易空间组成部分的附加资源
- 元数据（metadata）：关于相应资源的，但并非资源内容模型组成部分的重要信息
- 标签（Tags，标记）：贴附于资源之上，可用于定义诸如安全、工作流程之类额外操作行为的标签
每种资源的开头都是一套共同的元素（关于如下格式的文档记录，请参见资源定义格式<Resource Definition Format>）：
<[#content [Name]] xmlns="http://hl7.org/fhir"> [formats.html] <[extensibility.html extension]><!-- 0..* [extensibility.html Extension] [extensibility.html See Extensions] --></extension> <[extensibility.html modifierExtension]><!-- 0..* [extensibility.html Extension] [extensibility.html See Extensions] --></modifierExtension> <[base-definitions.html#Resource.language language] value="[[datatypes.html#code code]]"/><!-- 0..1 Human language of the content (BCP-47) --> <[narrative.html#Narrative text]><!-- 0..1 [narrative.html#Narrative Narrative] Text summary of resource content, for human interpretation --></text> <[references.html#contained contained]><!-- 0..* [references.html#contained Resource] [references.html#contained Contained Resources] --></contained> <!-- Defined Data Elements for Resource --> </[Name]>
这些元素的出现必须始终采用这种顺序。为了支持XML Schema和UML派生型代码的一致性定义，所有资源所共有的这些基本元素将首先出现。
可选型语言元素language规定的是采用[BCP 47之中所定义代码来编码的相应资源的基本语言。注意，并不是所有的资源内容都必须采用这种语言。如果要指定某种语言，则应当在叙述型文本（Narrative Text）上也对其加以指定。并不存在默认语言，尽管可以依据相应的应用语境来推断出某种语言。
语言元素的提供旨在支持索引（indexing）和可及性（accessibility）（比如，文本发音< text-to-speech >功能就会利用这种语言标签）。在处理叙述型内容（narrative）的时候，采用的则是HTML语言标签language。资源语言标签的提供旨在用于指定依据资源之中的数据所生成的备选呈现形式的语言。
1.12.0.2 资源元数据
元数据属性乃是关于特定资源及其行为表现如何的关键特征（方面）。鉴于实施方面的种种原因，这些元数据属性的表达不在相应资源的范围之内：
| 元数据项 | 类型 | 使用方法 |
|---|---|---|
| 逻辑标识符 Logical Id | 用于为相应资源提供逻辑标识的简单字符串。在同一服务器之上，在同一类型所有资源的空间之内，该标识符具有唯一性。在该服务器上，在该资源的整个生命周期内，该标识符是恒定不变的。 | |
| 版本标识符 Version Id |
每当资源内容变更的时候就相应地变更。可在资源引用（resource reference）之中对其加以引用。可用于保证更新依据的是资源的最新版本。 | |
| 最后修改日期 Last Modified Date | 每当资源内容变更的时候就相应地变更。可供系统或人员用来判断资源内容的现时性（currency，新旧程度，当前状态）。 |
逻辑标识符和版本标识符均区分大小写。标识符始终具有不透明性（opaque），因而系统不需要也不应当试图去确定它们的内部结构。在资源引用和URLs之中，必须始终采用相同的方式来表达一种标识符。标识符的长度可多达36个字符，并且可以含有小写ASCII字母、数字、连字符“-”和小数点“.”所构成的任意组合。
注意：这些数据元的表达不在相应资源的范围之内，因为：
- 在携带交换内容的封套（envelope）里面，它们几乎始终都是明确的，尤其是它们处在http和原子型标头（http and atom headers）之中
- 随着资源的管理、移动或复制，它们都会发生变化，甚至是在内容本身并未变更的情况下（尽管逻辑标识符的变更可能需要变更引用它的其他资源的内容）
资源的完整标识是利用该资源所存在的服务器地址、资源类型和逻辑标识符所构建的绝对URL，如http://test.fhir.org/rest/Patient/123（其中，123为逻辑标识符）。注意，实施项目不应当假设，对于字面所表示的特定服务器（literal server）来说，资源标识始终都是可以解析的——该服务器可能临时不可用，或者因为政策限制而不可用（如防火墙），或者在某些情况下，也可能实际上其并不存在（例如，对于RESTful环境之外资源的使用）。资源之间利用它们的标识来相互引用。这些引用允许是绝对的或相对的（关于进一步的讨论，请参见资源引用<Resource References>章节部分的内容）。将资源从一个服务器复制或移动到另一服务器，则意味着这些资源将获得新的标识。关于进一步的详情，请参见资源标识管理（Managing Resource Identity）章节部分的内容。
每当资源变更的时候，版本标识符和最后修改日期都要发生变更。因为与日期/时间相关联的内在不确定性和精密度限制，对于管理并发事宜和版本特异性引用来说，版本标识符更为有用。最后修改日期则有利于人员去确定或者说弄清相应资源之中信息的逻辑上的新旧程度（logical currency）。
在任何利用资源的环境当中，都将需要解决关于在交换过程中如何表达这些元数据要素的技术细节。关于进一步的详情，请参见借助于服务利用资源（Using Resources with Services）章节部分的内容。
1.12.0.3 版本之间的兼容性
一旦本技术规范变为完整的规范性技术规范，将适用下列规则。这些规则保证的是，在采用不同版本的FHIR技术规范在应用程序之间交换数据的同时，实施项目可以安全地处理资源内容。不过，在本技术规范试行期间，对于在本技术规范之中所发现的问题和事项，HL7可能会做出超出此处所描述的这些限制的变更。在试行期间，应用程序可能希望利用资源标签（resource tags）来帮助管理这种情况。
目前，在资源内容之中还没有任何明确的版本标志。一旦成为规范性的标准，本技术规范的后续版本则可能在资源内容之中的任何位置上引入新的元素和/或内容，但已有数据元的路径和含义则不会发生变化。为了收录新增的代码，则可能会对任何的取值集合或代码列表加以修订。
对于特定取值集合或代码系统的每次绑定表示的是，该取值列表是否会随着新增代码的定义而自动增长，是否可能会在本技术规范的未来版本之中对该列表加以扩充，或者是否在未来的版本之中根本不能对该列表加以变更。
符合性层面（conformance layer）（符合性< Conformance >和概貌< Profile >）具有用于声明FHIR技术规范版本的必备型属性，因而这些属性可以用来确定特定实施项目当前所采用的FHIR的版本。
在典型场景下，可能会需要若干版本的混合存在，因此应用程序应当忽略那些它们并不认识的元素，除非这些元素属于修饰型扩展modifierExtensions。然而，在医疗保健语境下，许多的应用程序厂商并不愿意考虑这种方法，因为这涉及到临床风险或者其软件之中的技术限制（比如，基于Schema的处理）。并不要求应用程序忽略未知元素，但其必须在符合性声明（conformance statements）当中声明它们将会这么做。
可在如下地址找到关于跨版本控制（inter-versioning）事宜的讨论：
1.12.0.3.1 进一步的信息
附加文档。
