工作组:FHIR Infrastructure 成熟度: Normative标准状态: Normative

FHIR被誉为使用REST风格的行业级“RESTful”规范。 实际上,FHIR的核心规范部分仅支持REST成熟度模型 的第2级,尽管通过使用 扩展 可以实现完整的第3级符合性。 由于FHIR是一个标准,它依赖于资源结构和接口的标准化。这一点可能被视为违反REST原则,但这却也是保证不同系统进行一致性交互的关键。

每种“资源类型”都定义了一组相同的交互功能,来实现以高粒度模块化的方式管理资源。 声称符合这种框架的应用程序即符合了"RESTful FHIR"。 (请参见 符合性章节).

注意,在这个RESTful框架中,事务是使用HTTP请求/响应机制直接在服务器资源上执行的。 API不直接负责身份验证、授权和审计收集——有关更多信息,请参阅安全页面。 这里介绍的交互都是指的同步模式,异步模式的使用见 异步请求模式

API将FHIR资源描述为对资源的一组操作(称为“交互”),其中单个资源实例具有的交互功能与其类型相对应。 服务器可以选择哪些交互功能可用,以及它们支持哪些资源类型。服务器应提供一份能力声明 ,以说明支持哪些交互功能和资源。

除了一些常用理论知识一般注意事项外,本页还定义了以下交互功能:

资源实例层级上的交互功能
read读取资源的当前状态
vread读取特定版本资源的状态
update根据ID更新已有资源(如果没有,则创建它)
patch通过提交一组变更来更新已有资源
delete删除某个资源
history检索特定资源的更改历史记录
资源类型层级上的交互功能
create使用服务器分配的ID创建新资源
search根据某些筛选条件搜索资源类型
history检索特定资源类型的更改历史记录
系统层面的交互功能
capabilities获取系统的功能声明
batch/transaction通过一次提交完成更新、创建或删除一组资源
history检索所有资源的更改历史记录
search根据某些过滤条件搜索所有资源类型

除了这些交互功能之外,FHIR还提供了一个操作框架,以实现 验证消息交换文档交换 。此外,还支持使用 GraphQL查询语言。

注意:如果FHIR规范未指定HTTP功能动作(也叫HTTP方式,HTTP方法,如OPTIONS),则只能使用基础HTTP协议强制要求实现的动作。

本页介绍的交互使用格式如下:

  VERB [基地址]/[资源类型]/[逻辑id] {?_format=[表述形式]}
  • VERB就是FHIR支持的几种HTTP方法,如GET/POST/PUT等
  • 方括号中的内容(“基地址”、“资源类型”、“逻辑id”)是必填项,在实际使用中方括号中的内容可以有以下几种:
  • 大括号{} 中的内容为可选项

由上述格式构成的URL地址应该遵循RFC 3986标准第6章附录A 的要求,即对某些字符串(特别是对搜索参数)要用百分号转义。

下列三种情况,FHIR规范会使用前缀下划线来区分受保护的名称和其他名称:

  • 为了将系统层面的历史检索、资源搜索交互和资源类型层级上的历史检索、资源搜索区分开。
  • 为了区分历史检索等在资源实例层级和资源类型层级上的相似交互功能。
  • 为了将适用于所有资源的通用搜索参数和资源专属搜索参数区分开。

另外,可以在交互操作名称之前将$字符作为前缀使用,以实现类RPC功能。这类功能可能是由本规范定义的,也可能由实施者自定义。

The Service Base URL is the address where all of the resources defined by this interface are found. The Service Base URL takes the form of 服务基地址(Base URL)是一个API接口地址,接口中定义的所有资源都可以在这个地址里找到。服务基地址格式如下:

http{s}://server{/path}

The path portion is optional, and does not include a trailing slash. Each resource type defined in this specification has a manager (or "entity set") that lives at the address /[type] where the [type] is the name of the resource type. For instance, the resource manager for the type Patient will live at: path部分是可选项,path后面没有斜线,每一种resource类型都有一个起点(或者叫实体集),在/[type]后面, 这个 [type]是resource的类型,举例来说,这个resource起点对Patient来说,就是这样的:

https://server/path/Patient

All the logical interactions are defined relative to the service root URL. This means that if the address of any one FHIR resource on a system is known, the address of other resources may be determined. 所有与病人相关的业务交互的URL对于根URL来说都是相对的。这就意味着所有FHIR resource在整个系统都是可知的, 其他的resource基本上也是可以以此类推的

Note: All URLs (and ids that form part of the URL) defined by this specification are case sensitive. Clients SHOULD encode URLs using UTF-8, and servers SHOULD decode them assuming they are UTF-8 (for background, see here ). 注意:所有规范定义的URL(所有组成URL部分的id)都是大小写敏感的。 客户端应该用utf-8对所有URL进行编码,服务端应该用UTF-8进行解码(原因在这里 )

Note that a server may use a path of the form http://server/...[xx]... where the [xx] is some variable portion that identifies a particular instantiation of the FHIR API. Typically, the variable id identifies a patient or a user, and the underlying information is completely compartmented by the logical identity associated with [xx]. In this case, the FHIR API presents a patient or user centric view of a record, where authentication/authorization is explicitly granted to the URL, on the grounds that some identifiable user is associated with the logical identity. It is not necessary to explicitly embed the patient id in the URL - implementations can associate a FHIR end-point with a particular patient or provider by using an OAuth login. See Compartments for the logical underpinning. 值得注意的是服务端可能会用这种形式即http://server/...[xx]...,这个 [xx]标明是FHIR API实例化中可变的部分。 比如,变量id可能代表是一个病人或者用户,id所代表的信息被[xx]所掩盖了。 在这种情况下,fhir api提供了一个 以患者或用户为中心的记录视图,其中身份验证/授权是 基于某些可识别用户关联的原因,显式授予该URL 具有逻辑身份。不需要在 URL嵌入病人的id,实现的方式可以是将fhir端点与特定患者关联,或者 通过使用OAuth登录名提供程序。 有关组织结构,请参阅compartments

Identity 标识

Systems often need to compare two URLs to determine whether they refer to the same underlying object or not. For the purposes of this specification, the following rules apply: 系统通常需要比较两个URL来确定它们是否引用同一个底层对象。 在本规范中,以下规则适用

  • The query part of the URL (anything after ?) is ignored URL的查询部分(在?之后)有任何内容吗的被忽略
  • The comparison of the document portion of the URL (i.e. not the server/port) is case sensitive URL的文档部分(即不是服务器/端口)的比较区分大小写
  • The protocols http: and https: SHALL NOT be used to refer to different underlying objects http:https:后相同的url不应该指向不同的底层对象
  • If a port is specified, then the ports must be identical or the objects are different (due to the prevalence of port mapping and/or interface engines running on different ports). Ports should only be explicit when they have explicit meaning to the server 如果指定了端口,则端口必须相同或对象不同(由于 在不同端口上运行的端口映射和/或接口引擎的流行率)。端口应 只有当它们对服务端有明确意义时才显现出来

For example: http://myserver.com/Patient/1 and https://myserver.com/Patient/1 refer to the same underlying object, while http://myserver.com:81/Patient/1 is a distinct entity from either of the above. This does not mean that the two addresses need to be treated the same, or that a server must serve both addresses, or that the content from the two addresses must be identical, but just that if these two addresses have the same identity, and if both are served, they must both represent the same underlying object. Systems are not required to check that this is true. Note: the identity comparison for protocols other than http:/https: is undefined. 例如: http://myserver.com/Patient/1https://myserver.com/Patient/1参考同一个基本对象,而http://myserver.com:81/Patient/1是一个实体从不同的代码上述任何。 这并不意味着需要处理的两个地址相同,或一个服务器的地址,必须是服务内容,或从两个地址必须相同,但如果只是这两个 地址是一样的形象,如果他们两个都是先到先得,必须代表相同的潜在对象。一个系统是不需要的 检查,这是真的。注:标识比其他协议的比较研究:是未定义:HTTP / HTTPS。

Each resource has an associated set of resource metadata elements. These map to the HTTP request and response using the following fields: 每个资源都有一组关联的资源元数据元素。这些映射到HTTP请求和响应,使用以下字段:

Metadata Item 元数据条目Where found in HTTP 可以在HTTP哪里可以找到
Logical Id (.id)The Id is represented explicitly in the URL 该ID在URL中显式表示。
Version Id (.meta.versionId)The Version Id is represented in the ETag header 版本id在ETag显示出来
Last modified (.meta.lastUpdated)HTTP Last-Modified header HTTP最终被修改的header

Note that the Version Id is considered a "weak" ETag and ETag headers should be prefixed with W/ and enclosed in quotes, for example: 请注意,版本ID被视为“弱”ETag和ETagheaders 应以w/作为前缀,并用引号括起来,例如:

ETag: W/"3141"

Using HTTPS is optional, but all production exchange of healthcare data SHOULD use SSL and additional security as appropriate. See HTTP Security for further information. Most operations will require user authentication, and all operations that do so are subject to RBAC and/or ABAC , and some operations may depend on appropriate consent being granted. 使用HTTPS是可选的,但所有医疗保健数据的生产交换都应使用SSL和 额外担保(视情况而定)。有关详细信息,请参阅http security。 大多数操作都需要用户身份验证,所有这样做的操作都是主题操作 至RBAC和/或ABAC, 一些行动可能取决于是否给予适当的权限。

Note: to support browser-based client applications, servers SHOULD implement cross-origin resource sharing (CORS) for the interactions documented here. 注意:为了支持基于浏览器的客户机应用程序,服务器应该为这里记录的交互实现跨域资源共享(CORS)

See the HTTP Security guidance for further information about both security generally and the use of CORS. 有关一般安全性和CORS使用的更多信息,请参阅HTTP安全指南

This specification makes rules about the use of specific HTTP status codes in particular circumstances where the status codes SHALL map to particular states correctly, and only where the correct status code is not obvious. Other HTTP status codes may be used for other states as appropriate, and this particularly includes various authentication related status codes and redirects. Authentication redirects should not be interpreted to change the location of the resource itself (a common web programming error). 此规范制定了有关使用特定HTTP状态代码的规则 在特定情况下,状态代码应映射到特定的 状态正确,并且只有在正确的状态代码不明显的地方。 其他HTTP状态代码可根据需要用于其他状态,尤其是 包括各种与身份验证相关的状态代码和重定向。 不应解释身份验证重定向以更改位置 资源本身(一个常见的Web编程错误)。

FHIR defines an OperationOutcome resource that can be used to convey specific detailed processable error information. For some combinations of interactions and specific return codes, an OperationOutcome is required to be returned as the content of the response. The OperationOutcome may be returned with any HTTP 4xx or 5xx response, but this is not required - many of these errors may be generated by generic server frameworks underlying a FHIR server. fhir定义了一个operationoutcome resource, 可用于传递特定的详细可处理错误信息。对于一些交互和特定返回代码的组合,需要将OperationOutcome作为响应的内容返回。 OperationOutcome可以随任何HTTP 4xx5xx响应一起返回, 但这不是必需的-这些错误中的许多可能是由fhir服务器底层的通用服务器框架生成的。

If the server has a default timezone, it SHOULD return the default timezone in the HTTP Response headers using the "Date" header. 如果服务器具有默认时区,则应使用"Date"头返回HTTP响应头中的默认时区。 为了管理带宽,此规范允许客户机指定要为资源返回的内容类型。

In the interests of managing band-width, this specification allows clients to specify what kind of content to return for resources. 为了管理带宽,本规范允许客户 指定要为资源返回的内容类型。

Clients may use the If-Modified-Since, or If-None-Match HTTP header on a read request. If so, they SHALL accept either a 304 Not Modified as a valid status code on the response (which means that the content is unchanged since that date) or full content (either the content has changed, or the server does not support conditional request). 客户端可以使用 If-Modified-Since,或者If-None-Matchread请求上的HTTP头匹配。如果是这样, 他们应接受304未修改为响应的有效状态代码(这意味着自该日期起内容保持不变)或完整内容(内容已更改,或服务器不支持有条件请求)。

Servers can return 304 Not Modified where content is unchanged because the If-Modified-Since date-time or the If-None-Match ETag was specified, or they can return the full content as normal. This optimisation is relevant in reducing bandwidth for caching purposes and servers are encouraged but not required to support this. If servers don't support conditional read, they just return the full content. 服务器可以返回304未修改因为 if modified since时间原因或者if none matchetag将会有值,或者他们会 正常返回全部内容。这种优化与减少用于缓存的带宽有关,鼓励使用服务器,但是 不需要支持这一点。如果服务器不支持条件读取,它们只返回完整的内容

These interactions are performed using POST, PUT or PATCH, and it may be appropriate for a server to return either only a status code, or also return the entire resource that is the outcome of the create or update (which may be different to that provided by the client). In the case of transactions this means returning a Bundle with just the Bundle.entry.response populated for each entry, and not the Bundle.entry.resource values. 这些交互是使用postputpatch,和 服务器可能只返回状态 代码,或者还返回作为 创建或更新(可能与 客户端)。在事务的情况下,这意味着返回一个bundle,其中每个条目只填充了bundle.entry.response 而不是bundle.entry.resourcevalues

The client can indicate whether the entire resource is returned using the HTTP return preference : 客户端可以指示整个资源是否 返回时使用http返回值首选

Prefer: return=minimal
Prefer: return=representation
Prefer: return=OperationOutcome
 首选:返回=最小
首选:返回=表示
首选:返回=操作结果

The first of these asks to return no body. The second asks to return the full resource. The third asks the server to return an OperationOutcome resource containing hints and warnings about the operation rather than the full resource. Servers SHOULD honor this header. In the absence of the header, servers may choose whether to return the full resource or not (but not the OperationOutcome; that should only be returned if explicitly requested). Note that this setting only applies to successful interactions. In case of failure, servers SHOULD always return a body that contains an OperationOutcome resource. 第一个要求不返回任何身体。这个 第二个请求返回完整的资源。第三问 要返回operationoutcome的服务器 包含有关操作的提示和警告的资源,而不是 完全资源。服务器应遵守此头。如果没有标题, 服务器可以选择是否返回完整的资源(但不返回操作结果); 只有在明确要求时才应返回)。注意这个设置 仅适用于成功的交互。如果出现故障,服务器应该 始终返回包含operationoutcome资源的正文。

See also the Asynchronous use pattern for another use of the Prefer header. 另请参见 异步使用模式 preferheader。

The formal MIME-type for FHIR resources is application/fhir+xml or application/fhir+json. The correct mime type SHALL be used by clients and servers: fhir资源的形式mime类型是application/fhir+xmlapplication/fhir+json。 客户端和服务器应使用正确的mime类型:

  • XML: application/fhir+xml
  • JSON: application/fhir+json
  • RDF: application/fhir+turtle (only the Turtle format is supported)

Servers SHALL support server-driven content negotiation as described in section 12 of the HTTP specification. 服务器应支持服务器驱动的内容协商,如第12节 中所述。 HTTP规范的。

Implementation Notes: 实现概要:

  • The content type application/x-www-form-urlencoded (Specification ) is also accepted for posting search requests. post搜索也支持类型为application/x-www-form-urlencoded (Specification )
  • If a client provides a generic mime type in the Accept header (application/xml, text/json, or application/json), the server SHOULD respond with the requested mime type, using the XML or JSON formats described in this specification as the best representation for the named mime type (except for binary - see the note on the Binary resource). 如果客户机在accept头文件(application/xml、text/json或application/json)中提供了一个通用的mime类型, 那么服务器应该使用请求的mime类型进行响应,使用本规范中描述的xml或json格式作为命名mime类型的最佳表示形式( binary除外-请参见binary资源的注释)
  • Note: between FHIR DSTU2 and STU3, the correct mime type was changed from application/xml+fhir and application/json+fhir to application/fhir+xml and application/fhir+json. Servers MAY also support the older mime types, and are encouraged to do so to smooth the transition process. 注意:在fhir dstu2和stu3之间,正确的mime类型从application/xml+fhirapplication/json+fhir更改为application/fhir+xmlapplication/fhir+json。 服务器还可以支持较旧的mime类型,并鼓励这样做以平滑过渡过程。
  • 406 Not Acceptable is the appropriate response when the Accept header requests a format that the server does not support, and 415 Unsupported Media Type when the client posts a format that is not supported to the server. 406 Not acceptable是正确的响应,当acceptheader 请求不被服务端 不支持,并且当客户端发布不支持的格式时,415 unsupported media type将会被返回

UTF-8 encoding SHALL be used for the mime type application/fhir. This MAY be specified as a MIME type parameter to the application/fhir mime type, but is not required. 对于mime类型application/fhir,应使用utf-8编码。这可以指定为 应用程序/fhir mime类型的mime类型参数,但不是必需的

This specification defines the MIME-type parameter fhirVersion as a parameter to indicate which version of the FHIR release a resource is based on: 本规范将mime type参数fhirversion定义为要指示的参数 fhir发布资源的哪个版本基于:

  Accept: application/fhir+json; fhirVersion=4.0

The value of this parameter is the publication and major version number for the specification: 此参数的值对于规范来说是 出版物和主要版本号

FHIR R1 (DSTU 1) 0.0
FHIR R2 (DSTU 2) 1.0
FHIR R3 (STU3, or just R3) 3.0
FHIR R4 (this version) 4.0 (once published)

Intermediate balloted releases may also be encountered occasionally - see publications directory . Versions from before the publication of the first DSTU (which is 0.0) are not supported. 偶尔也会遇到中间投票版本-请参见Publications directoryfirst dstu(即0.0)发布之前的版本不受支持。

This parameter can be used anywhere that the FHIR Mime type is used. When used in an HTTP request, the version parameter may be used on either the Content-Type header, or the Accept header, or both, and applies to the entire interaction (the behavior of the interactions as described on ths page, the search parameters and functionality, and the accompanying conformance resources). It is an error for a client to attempt to use two different versions in the same interaction. For further information about specifying FHIR version, see Managing FHIR Versions. 此参数可以在使用fhir mime类型的任何地方使用。在HTTP请求中使用时, 版本参数可用于内容类型头或接受头,或同时用于两者,以及 适用于整个交互(如本页所述的交互行为, 搜索参数和功能,以及附带的一致性资源)。这是一个错误 客户端试图在同一交互中使用两个不同的版本。有关 指定fhir版本,请参见管理fhir版本

The following parameters are defined for use with all of the interactions defined on this page: 以下参数定义用于此页上定义的所有交互:

_format Override the HTTP content negotiation - see immediately below 重写HTTP内容协商-请参见下面的内容
_pretty Ask for a pretty printed response for human convenience - see below 为方便起见,请提供一份印刷精美的回复-见下文。
_summary Ask for a predefined short form of the resource in response - see Search Summary 请求预先定义的资源简短形式作为响应-请参阅搜索摘要
_elements Ask for a particular set of elements to be returned - see Search Elements 要求返回一组特定的元素-请参阅搜索元素

Note that the impact of _elements is not defined for interactions other than search where the response is a bundle that contains more than one type of resource. 注意,没有为响应所在的搜索以外的交互定义元素的影响。 包含多个资源类型的包。

_format

In order to support various implementation limitations, servers SHOULD support the optional _format parameter to specify alternative response formats by their MIME-types. This parameter allows a client to override the accept header value when it is unable to set it correctly due to internal limitations (e.g. XSLT usage). For the _format parameter, the values xml, text/xml, application/xml, and application/fhir+xml SHALL be interpreted to mean the XML format, the codes json, application/json and application/fhir+json SHALL be interpreted to mean the JSON format, and the codes ttl, application/fhir+turtle, and text/turtle SHALL be interpreted to mean the Turtle RDF format. In addition, the values html and text/html are allowed. 为了支持各种实现限制,服务器应该支持可选的_format参数,以通过其mime类型指定可选的响应格式。此参数允许客户端在由于内部限制(如XSLT使用) 而无法正确设置接受头值时重写该值。对于格式参数,xmltext/xmlapplication/xmlapplication/fhir+xml值应解释为XML formatjsonapplication/jsonapplication/fhir+json代码应解释为JSON 格式ttlapplication/fhir+turtletext/turtle应解释为Turtle RDF format。此外,允许使用值htmltext/html

Note: the _format parameter does not override the Content-Type header for the type of the body of a POST request. If neither the accept header nor the _format parameter are specified, the MIME-type of the content returned by the server is undefined and may vary. 注意:_format参数不覆盖 Post请求Content-Type的类型。如果既没有指定accept header也没有指定_format参数,则mime类型 服务器返回的内容未定义,可能会有所不同。

_pretty

Clients that wish to request for pretty-printed resources (either in JSON or XML) can use the _pretty parameter: 希望请求漂亮打印资源(JSON或XML)的客户机可以 使用_pretty参数:

GET [基地址]/Patient/example?_pretty=true

Value values are true and false. Since pretty printed or not makes no difference to the content, this is only of interest for development tools, and servers MAY choose to support this parameter. 值是truefalse。因为印刷精美 不管内容有没有区别,这只是发展的兴趣 工具和服务器可以选择支持此参数。

Servers that support this API SHOULD provide full version support - that is, populate and track versionId correctly, support vread, and implement version aware updates. Supporting versions like this allows for related systems to track the correct version of information, and to keep integrity in clinical records. However, many current operational systems do not do this, and cannot easily be re-engineered to do so. 支持此API的服务器应提供完整版本支持—即填充和跟踪 versionIDcorrectly,supportvread,and implementversion Aware updates。 这样的支持版本允许相关系统跟踪正确的信息版本, 保持临床记录的完整性。然而,许多现行的操作系统却没有 这样做,就不容易被重新设计。

For this reason, servers are allowed to not provide versioning support and this API does not enforce that versioning is supported. Clients may elect to only interact with servers that do provide full versioning support. Systems declare their support for versioning in their Capability Statements, where they can indicate one of three levels for versioning support: 因此,允许服务器不提供版本控制支持,并且此API不强制 支持该版本控制。客户机可以选择只与提供完整服务的服务器进行交互。 版本控制支持。系统声明支持版本控制 在其capability statements中 它们可以表示版本控制支持的三个级别之一:

  • no-version: Versioning and meta.version is not supported (server) or used (client) 版本和meta.version不被服务端支持或客户端使用
  • versioned: Versioning and meta.version is supported (server) or used (client) 版本和meta.version被服务端支持或客户端使用
  • versioned-update: Versioning and meta.version is supported, and version aware updates are used - Version ID must be correct for updates (server) or will be specified (If-match header) for updates (client) 支持版本控制和meta.version,并使用版本感知更新-版本ID对于更新(server)必须正确,或者对于更新(client)将指定(如果匹配header)

Servers that do not support versioning SHALL ensure that Resource.meta.versionId is not present on resources they return, and SHALL update the value of Resource.meta.lastUpdated correctly. 不支持版本控制的服务器应确保Resource.meta.versionId上不存在 他们返回的资源,应正确更新resource.meta.lastupdated的值。

The read interaction accesses the current contents of a resource. The interaction is performed by an HTTP GET command as shown: readinteraction访问资源的当前内容。交互作用 由httpgetcommand执行,如图所示:

  GET [基地址]/[资源类型]/[id] {?_format=[mime-type]}

This returns a single instance with the content specified for the resource type. This url may be accessed by a browser. The possible values for the Logical Id ("id") itself are described in the id type. The returned resource SHALL have an id element with a value that is the [id]. Servers SHOULD return an ETag header with the versionId of the resource (if versioning is supported) and a Last-Modified header. 这将返回具有为资源类型指定的内容的单个实例。 浏览器可以访问此URL。的可能值 logical id(“id”)本身在id类型中描述。 返回的资源应具有一个值为id的元素。 服务器应返回一个带有资源版本ID的etagheader(如果支持版本控制)和一个last modifiedheader

Note: Unknown resources and deleted resources are treated differently on a read: a GET for a deleted resource returns a 410 status code, whereas a GET for an unknown resource returns 404. Systems that do not track deleted records will treat deleted records as an unknown resource. Since deleted resources may be brought back to life, servers MAY include an ETag on the error response when reading a deleted record to allow version contention management when a resource is brought back to life. 注意:未知资源和已删除资源在读取时的处理方式不同:get方式获取已删除的 resource返回410状态码,而get获取未知资源404将会被返回。系统 不跟踪已删除的记录将把已删除的记录视为未知资源。因为删除的资源可能会带来 回到生活中,当读取已删除的记录以允许版本时,服务器可能在错误响应中包含ETag。 资源恢复使用时的争用管理。

In addition, the search parameter _summary can be used when reading a resource: 此外,在读取资源时,可以使用搜索参数>summary

  GET [基地址]/[资源类型]/[id] {?_summary=text}

This requests that only a subset of the resource content be returned, as specified in the _summary parameter, which can have the values true, false, text, count and data. Note that a resource that only contains a subset of the data is not suitable for use as a base to update the resource, and might not be suitable for other uses. The same applies to the _elements parameter - both that it should be supported, and the subset implications. Servers SHOULD define a Resource.meta.tag with the SUBSETTED as a Simple Tag to explicitly mark such resources. 这要求只返回资源内容的一个子集, 如_summary中指定的,参数可以具有值 truefalsetextcountanddata。 请注意,只包含数据子集的资源是 不适合用作更新资源的基础,并且可能不适合 适用于其他用途。这同样适用于_elementsparameter-both 它应该得到支持,以及子集的含义。服务器应该定义一个resource.meta.tagwith SUBSETTED是一个 Simple Tag 明确标记这些资源。

A HEAD request can also be used - see below. 还可以使用head请求-请参见下文

The vread interaction performs a version specific read of the resource. The interaction is performed by an HTTP GET command as shown: vread交互对资源执行版本特定的读取。交互作用 由httpget执行,如图所示:

  GET [基地址]/[资源类型]/[id]/_history/[版本号] {?_format=[mime-type]}

This returns a single instance with the content specified for the resource type for that version of the resource. The returned resource SHALL have an id element with a value that is the [id], and a meta.versionId element with a value of [版本号]. Servers SHOULD return an ETag header with the versionId (if versioning is supported) and a Last-Modified header. 这将返回为该资源类型指定内容的单个实例 资源的版本。 返回的资源应具有一个值为idelement,该值为[id],和一个meta.versionid 值为[版本号]的元素。服务器应返回带有versionID的etagheader(如果支持版本控制) 和Alast modifiedheader.

The Version Id ("vid") is an opaque identifier that conforms to the same format requirements as a Logical Id. The id may have been found by performing a history interaction (see below), by recording the version id from a content location returned from a read or from a version specific reference in a content model. If the version referred to is actually one where the resource was deleted, the server should return a 410 status code. Version Idformat requirements格式要求的不透明标识符。 aLogical Id。通过执行历史交互(见下文),通过记录 从内容位置返回的版本ID,从中的版本特定read返回 内容模型。如果引用的版本实际上是删除资源的版本,则 服务器应返回410status code。

Servers are encouraged to support a version specific retrieval of the current version of the resource even if they do not provide access to previous versions. If a request is made for a previous version of a resource, and the server does not support accessing previous versions (either generally, or for this particular resource), it should return a 404 Not Found error, with an operation outcome explaining that history is not supported for the underlying resource type or instance. 鼓励服务端支持对当前版本的 资源,即使它们不提供对以前版本的访问。如果请求 是为资源的早期版本创建的,服务器不支持访问 以前的版本(通常,或者对于这个特定的资源),它应该 返回A404not found error,操作结果解释 基础资源类型或实例不支持历史记录。

A HEAD request can also be used - see below. 还可以使用head请求-请参见下文

The update interaction creates a new current version for an existing resource or creates an initial version if no resource already exists for the given id. The update interaction is performed by an HTTP PUT command as shown: updateinteraction为现有资源创建新的当前版本或 如果给定ID的资源不存在,则创建初始版本。 updateinteraction由httpput执行,如图所示:

  PUT [基地址]/[资源类型]/[id] {?_format=[mime-type]}

The request body SHALL be a Resource with an id element that has an identical value to the [id] in the URL. If no id element is provided, or the id disagrees with the id in the URL, the server SHALL respond with an HTTP 400 error code, and SHOULD provide an OperationOutcome identifying the issue. If the request body includes a meta, the server SHALL ignore the provided versionId and lastUpdated values. If the server supports versions, it SHALL populate the meta.versionId and meta.lastUpdated with the new correct values. Servers are allowed to review and alter the other metadata values, but SHOULD refrain from doing so (see metadata description for further information). Note that there is no support for updating past versions - see notes on the history interaction. 请求主体应为aresource,其中附上idelement 其值与URL中的[id]相同。如果没有提供idelement, 或者ID与URL中的ID不一致,服务器应以http400响应,并且应 提供一个识别问题的operationoutcome 如果请求主体包含meta,则服务端应 忽略所提供的versionIDlastupdated值。 如果服务器支持版本,则它应填充meta.versionIDmeta.lastupdated 使用新的正确值。允许服务器查看和更改其他元数据值,但应避免 这样做之后(请参阅元数据说明,了解更多信息)。注意 不支持更新以前的版本-请参阅>historyinteraction上的注释

A server SHOULD accept the resource as submitted when it accepts the update, and return the same content when it is subsequently read. However systems might not be able to do this; see the note on transactional integrity for discussion. Also, see Variations between Submitted data and Retrieved data for additional discussion around update behavior. Note that update generally updates the whole content of the resource. For partial updates, see patch below. 服务端在接受更新时应接受提交的资源,并返回相同的资源 随后读取的内容。但是,系统可能无法执行此操作;请参阅 有关transactional integrity的说明供讨论。 另外,有关其他讨论,请参见Variations between Submitted data and Retrieved data。 关于更新行为。请注意,update通常会更新资源的全部内容。为了部分 更新,请参见下面的patch

If the interaction is successful, the server SHALL return either a 200 OK HTTP status code if the resource was updated, or a 201 Created status code if the resource was created (or brought back to life/re-created), with a Last-Modified header, and an ETag header which contains the new versionId of the resource. If the resource was created (i.e. the interaction resulted in a 201 Created), the server SHOULD return a Location header (this is for HTTP conformance; it's not otherwise needed). The body of response is as described in Managing Return Content. 如果交互成功,服务器应返回A200OK HTTP状态代码 如果资源已更新,或如果资源已创建(或已带来),则为201 回到生活中/重新创建),其中last modifiedheader,和一个etagheader 包含资源的新版本ID。如果创建了资源(即交互 结果导致201created),服务器应返回一个locationheader( 是为了HTTP一致性;否则不需要)。响应主体如所述 在管理返回内容中

Note: Servers MAY choose to preserve XML comments, instructions, and formatting or JSON whitespace when accepting updates, but are not required to do so. The impact of this on digital signatures may need to be considered. 注意:服务器在接受更新时可以选择保留XML注释、说明和格式或JSON空白,但不需要这样做。可能需要考虑这对数字签名的影响。

Servers MAY choose to allow clients to PUT a resource to a location that does not yet exist on the server - effectively, allowing the client to define the id of the resource. Whether a server allows this is a deployment choice based on the nature of its relationships with the clients. While many servers will not allow clients to define their ids, there are several reasons why it may be necessary in some configurations: 服务器可以选择允许客户机将资源PUT 到 服务器上还不存在-有效地允许客户端定义 资源的ID。服务器是否允许这是基于部署选项的 关于其与客户关系的性质。而许多服务器 不允许客户端定义其ID,这有几个原因 在某些配置中是必需的

  • client is reproducing an existing data model on the server, and needs to keep original ids in order to retain ongoing integrity 客户机正在服务器上复制现有的数据模型,需要保留原始ID以保持持续的完整性。
  • client is a server doing push based pub/sub (this is a special case of the first reason) 客户机是执行基于push的pub/sub的服务器(这是第一个原因的特殊情况)
  • multiple clients doing push in the context of agreed data model shared across multiple servers where ids are shared across servers 多个客户机在多个服务器共享的商定数据模型的上下文中进行推送,其中ID在多个服务器之间共享。

Alternatively, clients may be sharing an agreed identification model (e.g. key server, scoped identifiers, or UUIDs) where clashes do not arise. Note that this use of update has security implications. 或者,客户机可以共享商定的标识模型(例如,密钥服务器、作用域标识符或UUID) 没有冲突的地方。请注意,使用updatesecurity implications

Servers can choose whether or not to support client defined ids, and indicate such to the clients using CapabilityStatement.rest.resource.updateCreate. 服务器可以选择是否支持客户端定义的ID,并向客户端指示这些ID。 使用CapabilityStatement.rest.resource.updateCreate

Servers are permitted to reject update interactions because of integrity concerns or other business rules, and return HTTP status codes accordingly (usually a 422). Note that there are potential security issues relating to how rejections are handled. See the security page for more information. 由于完整性问题或其他业务规则,允许服务器拒绝更新交互,并相应地返回HTTP状态代码(通常为a422)。 请注意,存在与如何处理拒绝相关的潜在安全问题。有关详细信息,请参阅 security page

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues): 在与fhir相关的错误上返回的常见HTTP状态代码(除了与安全性、头和内容类型协商问题相关的正常HTTP错误之外):

  • 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules (or multiple matches were found for conditional criteria) 无法分析资源或基本fhir验证规则失败
  • 401 Not Authorized - authorization is required for the interaction that was attempted尝试的交互需要授权
  • 404 Not Found - resource type not supported, or not a FHIR end-point不支持资源类型,或不是fhir端点
  • 405 Method Not allowed - the resource did not exist prior to the update, and the server does not allow client defined ids 更新之前资源不存在,服务器不允许客户端定义的ID
  • 409/412 - version conflict management - see below 版本冲突处理see 如下
  • 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules 建议的资源违反了适用的fhir配置文件或服务器业务规则

Any of these errors SHOULD be accompanied by an OperationOutcome resource providing additional detail concerning the issue. In general, if an instance fails the constraints documented in the CapabilityStatement then the response should be a 400, whereas if the instance fails other non-externally described business rules, the response would be a 422 error. However, there's no expectation that servers will tightly adhere to this differentiation (nor is it clear that it makes much difference whether they do or not). In practice, servers may also return 5xx errors in these cases without being deemed non-conformant. 这些错误中的任何一个都应该伴随一个 OperationOutcome resource,提供有关该问题的其他详细信息。 一般来说,如果一个实例没有通过capability语句中记录的约束,那么响应应该是400, 然而,如果实例失败了其他非外部描述的业务规则,那么响应将是422错误。然而, 没有人期望服务器会严格遵守这一区别(也不清楚它有多大的区别) 不管他们做不做)。实际上,在这些情况下,服务器还可能返回5xx个错误,而不会被视为不一致

For additional information on how systems may behave when processing updates, refer to the Variations between Submitted data and Retrieved data page. 有关系统在处理更新时的行为的其他信息,请参阅提交数据和检索数据之间的变化。

Unlike this rest of this page, the conditional create, update, patch and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. 与此页面的其余部分不同,条件创建、更新、修补和删除在 他们的使用获得了更多的经验。他们的状态将在未来版本的fhir中进行审查。

The conditional update interaction allows a client to update an existing resource based on some identification criteria, rather than by logical id. To accomplish this, the client issues a PUT as shown: 条件更新交互允许客户机根据某些标识标准更新现有资源, 而不是通过logical id来实现。要完成此操作,客户端将发出一个put

  PUT [基地址]/[资源类型]?[search parameters]

When the server processes this update, it performs a search using its standard search facilities for the resource type, with the goal of resolving a single logical id for this request. The action it takes depends on how many matches are found: 当服务器处理此更新时,考虑到解析单个请求的逻辑id时,将对resource type使用其标准搜索 search facilities它所采取的行动取决于 找到多少匹配项:

  • No matches, no id provided: The server creates the resource. 服务器创建资源
  • No matches, id provided: The server treats the interaction as an Update as Create interaction (or rejects it, if it does not support Update as Create) 服务器将交互视为Update as Create(如果不支持创建时的更新,则拒绝)
  • One Match, no resource id provided OR (resource id provided and it matches the found resource): The server performs the update against the matching resource 服务器对匹配的资源执行更新
  • One Match, resource id provided but does not match resource found: The server returns a 400 Bad Request error indicating the client id specification was a problem preferably with an OperationOutcome 服务器返回一个400bad request错误,指示客户端ID规范是一个问题,最好是一个operationoutcome
  • Multiple matches: The server returns a 412 Precondition Failed error indicating the client's criteria were not selective enough preferably with an OperationOutcome 前置条件失败错误指示 客户的标准没有足够的选择性,最好是操作结果。

This variant can be used to allow a stateless client (such as an interface engine) to submit updated results to a server, without having to remember the logical ids that the server has assigned. For example, a client updating the status of a lab result from "preliminary" to "final" might submit the finalized result using PUT path/Observation?identifier=http://my-lab-system|123 此变量可用于允许无状态客户端(如接口引擎)提交 将结果更新到服务器,而不必记住服务器分配的逻辑ID。 例如,客户机将实验室结果的状态从“初步”更新为“最终” 是否可以使用PUT path/Observation?identifier=http://my-lab-system|123

Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the conditional update SHOULD return an HTTP 400 error and MAY include an OperationOutcome. 请注意,事务和条件创建/更新/删除是复杂的交互,它是 不是每个服务器都会实现它们。不支持条件的服务器 更新应返回一个http400error,并可能包括一个OperationOutcome

The resource MAY contain an id element, but does not need to (this is one of the few cases where a resource exists without an id element). If an id is provided, the server SHALL ignore it - see documentation for the update interaction. 资源可能包含一个idelement,但不需要(这是 资源存在时没有idelement)的少数情况之一。 如果提供了id,服务器应忽略它-参见文档 对于update 交互

Lost Updates , where two clients update the same resource, and the second overwrites the updates of the first, can be prevented using a combination of the ETag and If-Match header. This is also known as 'Optimistic Locking'. Lost Updates ,在两个相同的客户端更新 资源,第二个位置的第一overwrites更新,可以使用一prevented组合 ETag If-Match 头。 这是被称为"乐观锁"

To support this usage, servers SHOULD always return an ETag header with each resource: 为了支持这种用法,服务器应始终返回每个资源的etagheader

HTTP 200 OK
Date: Sat, 09 Feb 2013 16:09:50 GMT
Last-Modified: Sat, 02 Feb 2013 12:02:47 GMT
ETag: W/"23"
Content-Type: application/fhir+json

If provided, the value of the ETag SHALL match the value of the version id for the resource. Servers are allowed to generate the version id in whatever fashion that they wish, so long as they are valid according to the id data type, and are unique within the address space of all versions of the same resource. When resources are returned as part of a bundle, there is no ETag, and the versionId of the resource is used directly. 如果提供,则ETag值应与资源的版本ID的值匹配。服务器 允许以他们希望的任何方式生成版本ID,这么长时间 因为根据id,它们是有效的, 在同一资源的所有版本的地址空间中都是唯一的。 当资源作为包的一部分返回时,没有ETag,并且 直接使用资源的versionID

If the client wishes to request a version aware update, it submits the request with an If-Match header that quotes the ETag from the server: 如果客户机希望请求一个版本感知更新,它将用 if matchheader,这个header是从服务端的ETag而来 :

PUT /Patient/347 HTTP/1.1
If-Match: W/"23"

If the version id given in the If-Match header does not match, the server returns a 412 Precondition Failed status code instead of updating the resource. 如果if matchheader中给出的版本ID不匹配,服务器将返回 412 precondition failed状态码而不是更新资源.

Servers can require that clients provide an If-Match header by returning 400 Client Error status codes when no If-Match header is found. Note that a 409 Conflict can be returned when the server detects the update cannot be done (e.g. due to server side pessimistic locking). 服务器可以要求客户端提供一个if matchheader,方法是返回400 client error 状态代码when noif matchheader is found.注意,当 服务器检测到无法完成更新(例如,由于服务器端的悲观锁定)

除了一次性更新整个资源外,客户端还可以执行修补操作以实现局部更新。 这种方式可以最大限度的节约带宽,另外,在当客户机只有局部访问权限或仅对某资源的部分元素提供支持时此方式会很用。 patch交互由HTTP PATCH 动作执行,如图所示

  PATCH [基地址]/[资源类型]/[id] {?_format=[mime-type]}

PATCH操作的消息体必须用以下三种形式其中之一提交:

在以上任何一种情况下,服务器都必须按指定的格式处理自己的资源副本,并遵循相关的PATCH规范来执行文档中指定的操作(如:添加、替换、插入等)。 当所有操作都已处理完时,服务器将结果文档、版本、错误处理以及Prefer Header等都视为Update动作来处理。

执行PATCH动作可能对版本非常敏感。因此,服务器必须支持带条件的PATCH,其工作方式与在并发管理中指定的更新完全相同。 客户端在使用PATCH动作时应该始终考虑指定版本,避免执行不适当的操作。

与此页面的其余部分不同,带条件的创建、更新、修补和删除在进一步实践之前是试用状态。他们的状态将在FHIR的未来版本中进行审查。

In addition, servers that support PATCH, and that support Conditional Update SHOULD also support conditional PATCH. When the server processes a conditional PATCH, it performs a search using its standard search facilities for the resource type, with the goal of resolving a single logical id for this request. The action it takes depends on how many matches are found: 此外,支持补丁的服务器,以及支持Conditional Update的服务器 也支持条件补丁。当服务器处理条件修补程序时,它使用其标准执行搜索 search facilitiesfor the resource type,with the goal of resolving a single logical id for this request.它所采取的行动取决于 找到多少匹配项

  • No matches: The server returns a 404 Not Found 服务器返回404未找到
  • One Match: The server performs the update against the matching resource 服务器对匹配的资源执行更新
  • Multiple matches: The server returns a 412 Precondition Failed error indicating the client's criteria were not selective enough 服务器返回一个412的前置条件失败错误,指示客户端的条件没有足够的选择性

The server SHALL ensure that the narrative in a resource is not clinically unsafe after the PATCH operation is performed. Exactly how this is defined and can be achieved depends on the context, and how narrative is being maintained, but servers may wish to consider: 服务端应确保在执行补丁操作后,资源中的叙述不具有临床安全性。 具体如何定义和实现这一点取决于上下文,以及如何维护叙述,但服务器可能希望考虑:

  • If the existing narrative has a status != generated, the server could reject the PATCH operation 如果现有的叙述有status!=generated,服务器可以拒绝补丁操作
  • The server could regenerate the narrative once the operation has been applied to the data 一旦操作应用于数据,服务器就可以重新生成叙述
  • In some limited circumstances, an XML PATCH operation could update the narrative 在某些有限的情况下,XML补丁操作可以更新叙述
  • The server could delete the narrative, on the basis that some later process will be able to populate it correctly 服务端可以删除叙述,因为以后的某个进程可以正确地填充它

Processing XML Patch documents is tricky because of namespace handling. Servers SHALL handle namespaces correctly, but note that FHIR resources only contain two XML namespaces, for FHIR (http://hl7.org/fhir) and XHTML (http://www.w3.org/1999/xhtml). 由于命名空间处理,处理XML修补程序文档很困难。服务器应处理 名称空间正确,但请注意,fhir resources只包含两个XML名称空间, 对于fhir(http://hl7.org/fhir)和xhtml(http://www.w3.org/1999/xhtml

For PATCH Examples, see the FHIR test cases. PATHC的例子,参见FHIR测试用例

Patch operations may be performed as part of Batch or Transaction Operations using the FHIRPath Patch format. Patch操作可以作为批处理或事务操作的一部分使用fhirpath Patch格式执行

Patch is not defined for all resources - see not about PATCH on Binary. 所有资源都支持Patch,参见 非关于Ptch二进制

The delete interaction removes an existing resource. The interaction is performed by an HTTP DELETE command as shown: DELETE交互将删除现有资源。交互由HTTPDELETE命令执行,如图所示

  DELETE [基地址]/[资源类型]/[id]

The request body SHALL be empty. 请求的body应该为空

A delete interaction means that subsequent non-version specific reads of a resource return a 410 HTTP status code and that the resource is no longer found through search interactions. Upon successful deletion, or if the resource does not exist at all, the server should return either a 200 OK if the response contains a payload, or a 204 No Content with no response payload, or a 202 Accepted if the server wishes to be non-commital about the outcome of the delete. delete交互意味着随后的资源的非版本特定读取 返回一个410http状态代码,并且通过搜索不再找到该资源 相互作用。成功删除后,或者如果资源根本不存在,服务器应返回 200 OKif the response contains a payload,or a204 no contentwithout no response payload, 或者,如果服务器希望不提交删除的结果,则接受202

Whether to support delete at all, or for a particular resource type or a particular instance is at the discretion of the server based on the policy and business rules that apply in its context. If the server refuses to delete resources of that type as a blanket policy, then it should return the 405 Method not allowed status code. If the server refuses to delete a resource because of reasons specific to that resource, such as referential integrity, it should return the 409 Conflict status code. Note that the servers MAY choose to enforce business rules regarding deletion of resources that are being referenced by other resources, but they also MAY NOT do so. Performing this interaction on a resource that is already deleted has no effect, and the server should return either a 200 OK if the response contains a payload, or a 204 No Content with no response payload. Resources that have been deleted may be "brought back to life" by a subsequent update interaction using an HTTP PUT. 是否支持delete,或者特定资源类型或特定实例位于 服务器根据其上下文中应用的策略和业务规则进行判断。 如果服务器拒绝将该类型的资源作为一揽子策略删除,则应返回 方法不允许的状态代码。如果服务器由于特定原因拒绝删除资源 对于该资源(如引用完整性),它应返回409conflict status code。 请注意,服务器可能会选择强制执行有关删除其他资源引用的资源的业务规则,但也可能不会这样做。 对已删除的资源执行此交互没有效果,服务器应返回 200 OK如果响应有数据,或者状态码为204 no content没有数据. 已删除的资源可能会由后续的update“还原” 使用HTTPPUT

Many resources have a status element that overlaps with the idea of deletion. Each resource type defines what the semantics of the deletion interactions are. If no documentation is provided, the deletion interaction should be understood as deleting the record of the resource, with nothing about the state of the real-world corresponding resource implied. 许多resource都有一个与删除概念重叠的状态元素。每种resource类型 定义删除交互的语义。如果未提供文件,则 删除交互应理解为删除resource的记录,而不进行任何操作。 关于现实世界中相应resource的状态暗示。

For servers that maintain a version history, the delete interaction does not remove a resource's version history. From a version history respect, deleting a resource is the equivalent of creating a special kind of history entry that has no content and is marked as deleted. Note that there is no support for deleting past versions - see notes on the history interaction. Since deleted resources may be brought back to life, servers MAY include an ETag on the delete response to allow version contention management when a resource is brought back to life. 对于维护版本历史记录的服务器,deleteinteraction does not 删除resource的版本历史记录。从版本历史的角度来看, 删除resource等同于创建具有 没有内容并标记为已删除。注意 不支持删除以前的版本-请参阅history交互上的注释。 由于删除的资源可能会恢复使用,服务器可能会在删除响应上包含一个etag 当resource恢复使用时,允许版本争用管理。

Note that irrespective of this rule, servers are free to completely delete the resource and it's history if policy or business rules make this the appropriate action to take. 请注意,无论此规则如何,服务器都可以自由地完全删除resource及其历史记录。 如果政策或业务规则使这成为要采取的适当行动

Unlike this rest of this page, the conditional create, update, patch and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. 与此页面的其余部分不同,条件创建、更新、修补和删除在 他们的使用获得了更多的经验。他们的状态将在未来版本的fhir中进行审查。

The conditional delete interaction allows a client to delete an existing resource based on some selection criteria, rather than by a specific logical id. To accomplish this, the client issues an HTTP DELETE as shown: 条件删除交互允许客户端根据某些选择条件删除现有resource, 而不是通过特定的逻辑ID。为此,客户机发出一个httpdelete

  DELETE [基地址]/[资源类型]/?[search parameters]

When the server processes this delete, it performs a search as specified using the standard search facilities for the resource type. The action it takes depends on how many matches are found: 当服务器处理此删除时,它将使用标准执行指定的搜索 search facilities.搜索取决于 找到多少匹配项:

  • No matches or One Match: The server performs an ordinary delete on the matching resource No matchesOne Match:服务器对匹配资源执行普通的delete
  • Multiple matches: A server may choose to delete all the matching resources, or it may choose to return a 412 Precondition Failed error indicating the client's criteria were not selective enough. A server indicates whether it can delete multiple resources in its Capability Statement (.rest.resource.conditionalDelete) 服务端可以选择删除所有匹配的资源,也可以选择返回一个412前置条件不满足错误,指示客户端的条件没有足够的选择性。 服务端指示是否可以在其功能语句中删除多个资源。Capability Statement (.rest.resource.conditionalDelete)

This variant can be used to allow a stateless client (such as an interface engine) to delete a resource on a server, without having to remember the logical ids that the server has assigned. For example, a client deleting a lab atomic result might delete the resource using DELETE /Observation?identifier=http://my-lab-system|123. 此变量可用于允许无状态客户端(如接口引擎)删除 服务器上的资源,不必记住服务器分配的逻辑ID。 例如,客户机删除实验室原子结果可能会使用DELETE /Observation?identifier=http://my-lab-system|123

Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the conditional update SHOULD return an HTTP 400 error and MAY include an OperationOutcome. 请注意,事务和条件创建/更新/删除是复杂的交互,它是 不是每个服务器都会实现它们。不支持条件的服务器 更新应返回一个http400error,并可能包括一个OperationOutcome.。

The create interaction creates a new resource in a server-assigned location. If the client wishes to have control over the id of a newly submitted resource, it should use the update interaction instead. The create interaction is performed by an HTTP POST command as shown: create交互在服务器分配的位置创建新资源。如果客户端 希望控制新提交资源的ID,它应该使用update 。通过httppost之上的createinteraction,如图所示:

  POST [基地址]/[资源类型] {?_format=[mime-type]}

The request body SHALL be a FHIR Resource. The resource does not need to have an id element (this is one of the few cases where a resource exists without an id element). If an id is provided, the server SHALL ignore it. If the request body includes a meta, the server SHALL ignore the existing versionId and lastUpdated values. The server SHALL populate the id, meta.versionId and meta.lastUpdated with the new correct values. Servers are allowed to review and alter the other metadata values, but SHOULD refrain from doing so (see metadata description for further information). 请求主体应为FHIR资源。资源不需要具有idelement(this is 资源存在时没有idelement)的少数情况之一。如果提供了id 服务器应忽略它。如果请求主体包含一个meta,服务器应 忽略现有的versionIDlastupdatedvalues。 服务器应填充idmeta.versionidandmeta.lastupdated 使用新的正确值。允许服务器查看和更改其他元数据值,但应该 不要这样做(有关详细信息,请参阅元数据说明)

A server SHOULD otherwise accept the resource as submitted when it accepts the create, and return the same content when it is subsequently read. However some systems might not be able to do this; see the note on transactional integrity for discussion. 否则,服务器在接受创建时应接受提交的资源,并返回相同的resource。 随后读取的内容。但是,某些系统可能无法执行此操作;请参阅 有关transactional integrity的说明供讨论。

The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version: 服务器返回一个201created http状态代码,还应返回一个locationheader 包含新的逻辑ID和版本ID 创建的资源版本:

  Location: [基地址]/[资源类型]/[id]/_history/[版本号]

where [id] and [版本号] are the newly created id and version id for the resource version. The Location header should be as specific as possible - if the server understands versioning, the version is included. If a server does not track versions, the Location header will just contain [基地址]/[资源类型]/[id]. The Location MAY be an absolute or relative URL. 其中[id]and[版本号]为新建的id和版本id. 位置头应尽可能具体-如果服务器了解版本控制,则版本为 包括。如果服务器不跟踪版本,则位置头将只包含[基地址]/[资源类型]/[id]。这个 位置可以是绝对或相对URL

Servers SHOULD return an ETag header with the versionId (if versioning is supported) and a Last-Modified header. The body of response is as described in Managing Return Content. 服务器应返回带有versionID的etagheader(如果支持版本控制)和last modifiedheader。 响应主体如管理返回内容中所述。

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error. 当resource语法或数据不正确或无效,并且无法用于创建新resource时,服务器将返回一个400的错误码。 当服务器由于业务规则而拒绝资源的内容时,服务器返回一个422unprocessed entity error http status code。 在这两种情况下,服务器都应该包含包含OperationOutcome的响应正文,其中包含描述错误原因的详细错误消息

Note: Servers MAY choose to preserve XML comments, instructions, and formatting or JSON whitespace when accepting creates, but are not required to do so. The impact of this on digital signatures may need to be considered. 注意:服务器可以选择保留XML注释、说明和格式或JSON。 接受创建时使用空白,但不需要这样做。可能需要考虑这对数字签名的影响。

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues): 在与fhir相关的错误上返回的常见HTTP状态代码 (除了与安全性、头和内容类型协商问题相关的正常HTTP错误之外)

  • 400 Bad Request 错误请求 - resource could not be parsed or failed basic FHIR validation rules 无法分析resource或基本fhir验证规则失败
  • 404 Not Found -不支持resource类型,或不是fhir支持的接入点
  • 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail 违反建议的resource适用 fhir配置文件或服务器业务规则。这应该伴随一个OperationOutcome resource 提供附加细节

In general, if an instance fails the constraints documented in the CapabilityStatement then the response should be a 400, whereas if the instance fails other non-externally described business rules, the response would be a 422 error. However, there's no expectation that servers will tightly adhere to this differentiation (nor is it clear that it makes much difference whether they do or not). In practice, servers may also return 5xx errors in these cases without being deemed non-conformant. 一般来说,如果一个实例没有通过CapabilityStatement中记录的约束,那么响应应该是400, 然而,如果实例失败了其他非外部描述的业务规则,那么响应将是422错误。然而, 没有人期望服务器会严格遵守这一区别(也不清楚它有多大的区别) 不管他们做不做)。实际上,在这些情况下,服务器还可能返回5xx个错误,而不会被视为不一致。

For additional information on how systems may behave when processing updates, refer to the Variations between Submitted data and Retrieved data page. 有关处理更新时系统的行为的其他信息,请参阅 Submitted Data和Retrieved Data之间的变化页。

Unlike this rest of this page, the conditional create, update, patche and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. 与此页面的其余部分不同,条件create, update, patche 和 delete 在 他们的使用获得了更多的经验。他们的状态将在未来版本的fhir中进行审查

The conditional create interaction allows a client to create a new resource only if some equivalent resource does not already exist on the server. The client defines what equivalence means in this case by supplying a FHIR search query using an HL7 defined extension header "If-None-Exist" as shown: 条件create交互只允许客户端在某些等效资源的情况下创建新资源 服务器上不存在。客户通过提供 使用HL7定义的扩展头"if none exist"的fhir搜索查询,如图所示:

  If-None-Exist: [search parameters]

The parameter just contains the search parameters (what would be in the URL following the "?"). 参数只包含搜索参数(URL中的“?”后面是什么)

When the server processes this create, it performs a search as specified using its standard search facilities for the resource type. The action it takes depends on how many matches are found: 当服务器处理此创建时,它将使用其标准执行指定的搜索 earch facilitiesf它所采取的行动取决于 找到多少匹配项

  • No matches: The server processes the create as above 服务器如上所述处理创建
  • One Match: The server ignores the post and returns 200 OK 服务器忽略post并返回20
  • Multiple matches: The server returns a 412 Precondition Failed error indicating the client's criteria were not selective enough 服务器返回一个412的前置条件失败错误,指示客户端的条件没有足够的选择性。

This variant can be used to avoid the risk of two clients creating duplicate resources for the same record. For example, a client posting a new lab result might specify If-None-Exist: identifier=http://my-lab-system|123 to ensure it does not create a duplicate record. 此变体可用于避免两个客户的风险 为同一记录创建重复resource。例如,发布新实验室结果的客户机可能会指定 if none exist:identifier=http://my lab system_123以此保证不包含重复记录.

Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the conditional update SHOULD return an HTTP 400 error and MAY include an OperationOutcome. 请注意,事务和条件 create/update/delete是复杂的交互,它是 不是每个服务器都会实现它们。不支持条件的服务器 更新应返回一个http400error,并可能包括一个OperationOutcome

此交互根据某些筛选条件搜索一组资源。交互可以由几个不同的HTTP动作执行。

  GET [基地址]/[资源类型]{?[参数]{&_format=[mime-type]}}

此语法通过参数中提供的条件搜索指定类型的所有资源。

因为有些用户除了使用上述基于GET的搜索方法之外,还用代理的方式处理GETPOST请求, 所以支持搜索 的服务器必须支持基于POST的搜索:

POST  [基地址]/[资源类型]/_search{?[参数]{&_format=[mime-type]}}
Content-Type: application/x-www-form-urlencoded

参数1=值&参数2=值

这与等效的GET动作具有完全相同的语义。 注意,在POST变量中,参数可能同时出现在URL和body消息体中。参数在任何地方都有相同的含义。 既然参数可以重复,将它们放在两个地方和重复使用效果相同(这对某些参数来说是合法的,其他一些参数则不合法)。

注意:支持GET意味着PHI(个人健康信息)可能出现在搜索参数和HTTP日志中。 因此,应将日志的敏感性视为与资源本身一致。这是一项一般要求,与使用GET无关 -有关进一步的说明,请参阅 安全

所有这些搜索交互都采用一系列编码在URL中的成对 name=[value]参数, 或者通过POST动作以 application/x-www-form-urlencoded格式的Body消息体提交。 ( 使用POST提交的规范 ,详见 W3C HTML表单 )

注意:POST支持application/x-www-form-urlencoded , 因此用GET POST 来调用搜索可以通过浏览器中的HTML表单来完成(尽管浏览器中可能需要相当多的活动内容),尽管这不是其主要用途。

也可以用HEAD请求- 详见下

搜索将按照指定的搜索处理机制进行处理。

如果搜索成功,服务器必须返回200 OK HTTP状态码,返回内容 必须 Bundle.type = searchset资源捆束,此搜索结果按照定义的顺序包含了零到多个资源。 请注意,搜索返回的资源捆束中的资源可能位于另一台服务器上,而不是在执行搜索的服务器上。 (即 Bundle.entry.fullUrl 可能与搜索URL的[基地址]不同)。

搜索结果集合可能很长,因此服务器可能使用分页。如果分页,必须使用下述方法 (采用 rfc 5005 - feed paging and archiving 标准)来将集合拆分为多个页面。服务器返回的 searchset 类型资源捆束条目中 还可能包含一个有关搜索的额外信息的 操作结果 资源;如果返回的资源捆束中含有操作结果资源,则OperationOutcome.issues.severity的编码值不能 fatal error ,并且 Bundle.entry.search.mode 的编码值必须outcome

如果搜索失败(不能执行,不是没有匹配项), 返回值必须是状态代码4xx或5xx,并返回一个操作结果资源。

与FHIR相关的错误返回的常见HTTP状态代码如下(与安全性、头和内容类型协商相关的常见HTTP错误除外):

  • 400 Bad Request 错误的请求 - 搜索无法处理或未能通过FHIR基本验证规则
  • 401 Not Authorized 未授权 - 尝试的交互需要授权
  • 404 Not Found 未找到 - 不支持请求的资源类型,或不是FHIR终结点

搜索所有可能的资源的逻辑区块或某个特定的资源类型的逻辑区块,分别为:

  GET [基地址]/[逻辑区块]/[id]/*{?[参数]{&_format=[mime-type]}}
  GET [基地址]/[逻辑区块]/[id]/[type]{?[参数]{&_format=[mime-type]}}

在第一个URL中,字符"*"以文字形式出现在URL中,用来表示“所有类型”。 因此,例如,检索与id为23423445的医疗活动资源相关的LOINC编码为2951-2的所有观察资源:

  GET [基地址]/Encounter/23423445/Observation?code=2951-2  {&_format=[mime-type]}

请注意,FHIR定义了专用的“everything操作”以支持获取某个患者的所有相关记录 某个医疗活动的所有相关记录

还可以跨多种资源类型进行搜索:

  GET [基地址]?_type=Condition,Observation&[参数]{&_format=[mime-type]}

这是一个搜索Condition和Observation资源的请求。 在这种情况下,只能使用那些同时定义给Condition和Observation资源的参数 (使用 SearchParameter.base - 参见 跨资源的搜索参数),或为所有资源定义的参数。 如果搜索参数中所需的类型没有在SearchParameter.base中列出,就会出错,服务器应该返回一个400状态码。

也可以一次性搜索所有类型:

  GET [基地址]?[参数]{&_format=[mime-type]}

一次搜索所有资源时,只能使用全局性搜索参数,即:适用于所有资源的基础参数

The capabilities interaction retrieves the information about a server's capabilities - which portions of this specification it supports. The interaction is performed by an HTTP GET command as shown: capabilities交互检索有关服务器功能的信息-它支持此规范的哪些部分。 交互由httpgetcommand执行,如图所示

  GET [基地址]/metadata{?mode=[mode]} {&_format=[mime-type]}

Applications SHALL return a resource that describes the functionality of the server end-point. The information returned depends on the value of the mode parameter: 应用程序应返回描述服务器端点功能的资源。返回的信息取决于 在mode参数:

full (or mode not present)A Capability Statement that specifies which resource types and interactions are supported Capability Statement指定哪些资源类型 支持交互
normativeAs above, but only the normative portions of the Capability Statement 如上所述,但仅限于能力说明的规范部分
terminology A TerminologyCapabilities resource that provides further information about terminologies which are supported by the server TerminologyCapabilities的类型提供了更多的关于 服务器支持的术语

Servers MAY ignore the mode parameter and return a CapabilityStatement resource. Note: servers might be required to support this parameter in further versions of this specification. 服务器可以忽略模式参数并返回CapabilityStatement资源。 注意:在本规范的进一步版本中,可能需要服务器来支持此参数

If a 404 Unknown is returned from the GET, FHIR (or the specified version) is not supported on the nominated service url. An ETag header SHOULD be returned with the Response. The value of the ETag header SHALL change if the returned resource changes. 如果从get返回了404unknown,则在 指定的服务URL。应随响应一起返回etagheader。如果 返回了资源变化了。

Servers SHOULD check for the fhirVersion MIME-type parameter when processing this request. 处理此请求时,服务器应检查fhirVersion MIME-type parameter

The resource returned typically has an arbitrary id, and no meta element, though it is not prohibited. Capability statements can become quite large; servers are encouraged to support the _summary and _elements parameters on the capabilities interaction, though this is not required. In addition, servers are encouraged to implement the $subset and $implements operations to make it easy for a client to check conformance. 返回的资源通常有一个任意的ID,并且没有元元素,尽管它是不被禁止的。 功能声明可能会变得非常大;鼓励服务器支持 _summary_elements 功能交互的参数,尽管这不是必需的。此外,鼓励服务器 实现 $subset$implements 操作使客户机更容易检查一致性。

In addition to this capabilities interaction, a server may also choose to provide the standard set of interactions (read, search, create, update) defined on this page for the CapabilityStatement Resource end-point. This is different from the capabilities interaction: 除此之外,服务器还可以选择提供 在此页面上定义的标准交互集(readsearchcreateupdate) 对于CapabilityStatement Resource接入点。 这与capabilities交互:

capabilities interactionreturns a capability statement describing the server's current operational functionality 返回服务端当前支持的功能描述
CapabilityStatement end-pointmanages a repository of capability statements (e.g. the HL7 capability statement registry) 处理功能库(比如HL7的功能描述注册)

All servers are required to support the capabilities interaction, but servers may choose whether they wish to support the CapabilityStatement end-point, just like any other end-point. 所有服务器都需要支持功能交互,但服务器可以选择是否希望支持功能声明接入点, 就像其他接入点一样

Implementation Note:实现注意: In DSTU 2 and earlier, the resource that this interaction returned was named "Conformance". Clients often connect to a server, and use the capabilities interaction to check whether they are version and/or feature compatible with the server. Such clients should be able to process either a Conformance or a CapabilityStatement resource. 在DSTU2和更早的版本中,这个交互返回的资源被命名为“一致性”。 客户机经常连接到服务器,并使用功能交互检查它们是否为版本 和/或与服务器兼容的功能。这样的客户机应该能够处理一致性或者 CapabilityStatement资源。

The batch and transaction interactions submit a set of actions to perform on a server in a single HTTP request/response. The actions may be performed independently as a "batch", or as a single atomic "transaction" where the entire set of changes succeed or fail as a single entity. Multiple actions on multiple resources of the same or different types may be submitted, and they may be a mix of other interactions defined on this page (e.g. read, search, create, update, delete, etc.), or using the operations framework. batchtransaction交互在单个HTTP请求/响应中提交一组要在服务器上执行的操作。 这些操作可以作为“批处理”单独执行,也可以作为单个原子“事务”单独执行,其中 整个更改集作为单个实体成功或失败。对多个资源执行多个操作 可以提交相同或不同类型的,并且可以是定义的其他交互的组合 在此页面上(例如,readsearchcreateupdatedelete,etc.),或使用operations

The transaction mode is especially useful where one would otherwise need multiple interactions, possibly with a risk of loss of referential integrity if a later interaction fails (e.g. when storing a Provenance resource and its corresponding target resource, or and IHE-MHD transaction "Provide Document Resources" with a DocumentManifest, and some number of DocumentReference, List, and Binary resources). transaction模式特别有用,在这种情况下,可能需要多个交互。 如果以后的交互失败(例如存储时),则可能会丢失引用完整性 来源资源及其对应的目标资源,或和IHE-MHD transaction "Provide Document Resources" 带有一个documentmanifest,以及一些documentreference、list和binary资源)

Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the batches or transactions SHOULD return an HTTP 400 error and MAY include an OperationOutcome. 请注意,事务和条件创建/更新/删除是复杂的交互,它是 不是每个服务器都会实现它们。不支持批处理的服务器 或者,事务应返回http400,并且可能包括一个OperationOutcome

A batch or transaction interaction is performed by an HTTP POST command as shown: 批处理 or 事务处理 交互是通过HTTP POST 进行的,如下:

  POST [基地址] {?_format=[mime-type]}

The content of the post submission is a Bundle with Bundle.type = batch or transaction. Each entry SHALL carry request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or transaction what to do for the entry. If the HTTP command is a PUT or POST, then the entry SHALL contain a resource for the body of the action. The resources in the bundle are each processed separately as if they were an individual interaction or operation as otherwise described on this page, or the Operations framework. The actions are subject to the normal processing for each, including the meta element, verification and version aware updates, and transactional integrity. In the case of a batch each entry is treated as if an individual interaction or operation, in the case of a transaction all interactions or operations either succeed or fail together (see below). 提交后的内容是BundleBundle.type =batchor事务处理。 每个条目都应包含requestdetails(Bundle.entry.request) 它提供操作的HTTP详细信息,以便通知处理批处理或事务的系统。 入口的操作。如果http命令是aputpost,则输入 应包含行动主体的资源。 包中的资源都是单独处理的,就好像它们是单独的一样。 如本页所述的交互或Operations framework,或 框架每个动作都要经过正常的处理, 包括meta element、验证和版本感知更新, 以及transactional integrity。如果是每批 在事务处理的情况下,条目被视为单个交互或操作。 交互或操作要么成功,要么失败(见下文)

Examples: 例子:

For a batch, there SHALL be no interdependencies between the different entries in the Bundle that cause change on the server. The success or failure of one change SHOULD not alter the success or failure or resulting content of another change. Servers SHOULD validate that this is the case. Note that it is considered that servers execute the batch in the same order as that specified below for transactions, though the order of execution should not matter given the previous rule. 对于batch,不同条目之间不应存在相互依赖关系。 在导致服务器发生更改的包中。一次变革的成败应该 不改变另一个改变的成功或失败或结果内容。服务器应该 验证情况是否如此。注意,认为服务器执行批处理 尽管执行顺序与以下指定的交易顺序相同 不管前面的规则是什么。

References within a Bundle.entry.resource to another Bundle.entry.resource that is being created within the batch are considered to be non-conformant. 在bundle.entry.resource中引用到另一个bundle.entry.resource 在批内创建的被认为是不一致的。

When processing the batch, the HTTP response code is 200 Ok if the batch was processed correctly, regardless of the success of the operations within the Batch. To determine the status of the operations, look inside the returned Bundle. A response code on an entry of other than 2xx (200, 202 etc) indicates that processing the request in the entry failed. 处理批处理时,如果批处理正确,则HTTP响应代码为200 OK,无论 批处理中的操作。要确定操作的状态,请查看返回的包内部。上的响应代码 2xx(200,202等)以外的条目表示在条目中处理请求失败

For a transaction, servers SHALL either accept all actions and return a 200 OK, along with a response bundle (see below), or reject all resources and return an HTTP 400 or 500 type response. It is not an error if the submitted bundle has no resources in it. The outcome of processing the transaction SHALL NOT depend on the order of the resources in the transaction. A resource can only appear in a transaction once (by identity). 对于transaction,服务器应接受所有操作并返回一个200 OK,以及一个 响应捆绑包(请参见下文),或拒绝所有资源并返回HTTP400500type 反应。如果提交的包中没有资源,则不是错误。 处理交易的结果不应取决于订单。 事务中的资源。资源只能出现在事务中 一次(根据身份)

Because of the rules that a transaction is atomic where all actions pass or fail together and the order of the entries doesn't matter, there is a particular order in which to process the actions: 因为事务在所有操作通过或失败时是原子的 总之,条目的顺序并不重要,有一个特定的顺序来处理操作:

  1. Process any DELETE interactions 处理 DELETE交互
  2. Process any POST interactions 处理POST交互
  3. Process any PUT or PATCH interactions 处理PUT交互
  4. Process any GET or HEAD interactions 处理GETHEAD交互
  5. Resolve any conditional references 处理条件引用

If any resource identities (including resolved identities from conditional update/delete) overlap in steps 1-3, then the transaction SHALL fail. 如果在步骤1-3中有任何资源标识(包括从条件更新/删除中解析的标识)重叠, 那么交易就会失败。

A transaction may include references from one resource to another in the bundle, including circular references where resources refer to each other. When the server assigns a new id to any resource in the bundle which has a POST method as part of the processing rules above, it SHALL also update any references to that resource in the same bundle as they are processed (see about Ids in a bundle). References to resources that are not part of the bundle are left untouched. Version-specific references should remain as version-specific references after the references have been updated. Note that when building a transaction, a client can use arbitrarily chosen version references since they will all be re-assigned anyway. Servers SHALL replace all matching links in the bundle, whether they are found in the resource ids, resource references, elements of type uri, url, oid, uuid, and <a href="" & <img src="" in the narrative. Elements of type canonical are not replaced. 事务可以包括从一个资源到包中另一个资源的引用,包括 资源相互引用的循环引用。 当服务器为包中具有post方法的任何资源分配新的ID时 作为上述处理规则的一部分,它还应在同一包中更新对该资源的任何引用 已处理(请参见 about Ids in a bundle)。引用的资源不是 包裹的一部分未被触碰。应保留特定于版本的引用 更新引用后作为特定于版本的引用。注意 在构建事务时,客户机可以使用任意选择的版本引用 因为它们都将被重新分配。 服务器应替换包中的所有匹配链接,无论它们是否在资源ID中找到, resource references, 类型为 uriurloiduuid<a href=""&;<img src="". 不替换canonical类型的元素。

When processing a "POST" (create), the full URL is treated as the id of the resource on the source, and is ignored; the server generates an id for the resource. For updates, the server performs a mapping between the fullUrl specified and the local URL the server knows that instance as, if possible. If the server does not have a mapping for the fullUrl, the server ignores the base URL and attempts an update assuming the base is the same as the server base. This allows the same transaction bundle to be sent to multiple systems without changing the fullUrls for each target. 在处理“post”(创建)时,完整的URL将被视为 源,并被忽略;服务器为资源生成一个ID。对于更新, 服务器在指定的完整URL和服务器的本地URL之间执行映射 如果可能的话,尽可能了解这个实例。如果服务器没有完整URL的映射, 服务器忽略基URL并尝试更新,假定基URL相同 作为服务器基础。这允许将同一个事务包发送到多个系统 不更改每个目标的完整URL。

When processing a batch or transaction, a server MAY choose to honor existing logical ids (e.g. Observation/1234 remains as Observation/1234 on the server), but since this is only safe in controlled circumstances, servers may choose to assign new ids to all submitted resources, irrespective of any claimed logical id in the resource, or fullUrl on entries in the batch/transaction. 在处理批处理或事务时,服务器可以选择遵守现有的 逻辑ID(例如observation/1234remains asobservation/1234on the server),但是 由于这仅在受控环境下是安全的,服务器 可以选择为所有提交的资源分配新的ID,而不考虑任何声明 资源中的逻辑id或批处理/事务中的条目上的fullurlon

Conditional References 条件引用

When constructing the bundle, the client might not know the logical id of a resource, but it may know identifying information - e.g. an identifier. This situation arises commonly when building transactions from v2 messages. The client could resolve that identifier to a logical id using a search, but that would mean that the resolution to a logical id does not occur within the same transaction as the commit (as well as significantly complicating the client). Because of this, in a transaction (and only in a transaction), references to resources may be replaced by a search URI that describes how to find the correct reference: 当一束构建,客户可能不知道逻辑ID的资源,但它可以 信息技术-例如,识别标识符。这种情况通常当建筑arises 交易消息从V2的。它的客户端可以使用一个逻辑标识符,标识符 一个搜索,但这会意味着一个逻辑的ID号不可能在 作为同一交易提交的客户和工作人员complicating)。因为 这一交易,在交易中唯一的),可能是没有引用资源 URI是由搜索找到了正确的参考知识:

 <Bundle xmlns="http://hl7.org/fhir">
   <id value="20160113160203" />
   <type value="transaction" />
   <entry>
     <fullUrl value="urn:uuid:c72aa430-2ddc-456e-7a09-dea8264671d8" />
     <resource>
       <Observation>
         <subject>
            <reference value="Patient?identifier=12345"/>
         </subject>
         <--! rest of resource omitted -->
       </Observation>
     </resource>
     <request>
       <method value="POST" />
     </request>
   </entry>
 <Bundle>

The search URI is relative to the server's [基地址] path, and always starts with a resource type: [type]?parameters.... Only filtering parameters are allowed; none of the parameters that control the return of resources are relevant. 搜索URI相对于服务器的[基地址]路径,并且始终以开头 资源类型:[type]?parameters...。仅筛选参数 不允许;没有控制资源返回的参数 是相关的。

When processing transactions, servers SHALL: 在处理事务时,服务器应:

  • check all references for search URIs检查搜索uri的所有引用
  • For search URIs, use the search to locate matching resources 对于搜索uri,使用搜索查找匹配的资源
  • if there are no matches, or multiple matches, the transaction fails, and an error is returned to the user如果没有匹配项或多个匹配项,则事务失败,并向用户返回错误。
  • if there is a single match, the server replaces the search URI with a reference to the matching resource如果只有一个匹配项,服务器将用对匹配资源的引用替换搜索URI。

For a batch, or a successful transaction, the response the server SHALL return a Bundle with type set to batch-response or transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. For a failed transaction, the server returns a single OperationOutcome instead of a Bundle. 对于批处理或成功的事务,服务器应 返回Bundletype 设置为batch-response(批处理响应)或transaction response(事务响应),其中每个条目包含一个条目 以相同的顺序请求,处理条目的结果。对于失败的事务, 服务器返回一个 operationoutcome而不是捆绑包。

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header. 客户端可以使用返回的包来跟踪处理条目的结果, 以及服务器分配给资源的标识。每个入口元件应 包含一个详细说明处理response的 entry-HTTP状态代码,以及位置和etagheader values, 用于识别和版本控制资源。此外,资源 可能包含在条目中,如Prefer标题所指定

A server may choose to accept bundle types other than batch or transaction when POSTed to the [基地址] URL. 服务器可以选择接受bundle类型,而不是接受batchtransactionposted to the[基地址]url

Bundles of type history inherently have the same structure as a transaction, and can be treated as either a transaction or batch, so servers SHOULD accept a history Bundle - this makes it possible to replicate data from one server to another easily using a pub/sub model. Note, however, that the original transaction boundaries might not be represented in a history list, and a resource may occur more than once in a history list, so servers processing history bundles must have some strategy to manage this. When processing a history bundle via a transaction, any entries with the request method of POST must use the Bundle.entry.resource.id (which must match the Bundle.entry.response.location) for that resource so that references are preserved. bundle类型history拥有和transaction一样的结构, 可以被视为事务或批处理,因此服务器应该接受一个历史捆绑包-这使得 可以使用发布/子模型轻松地将数据从一个服务器复制到另一个服务器。但是,请注意 原始事务边界可能不在历史记录列表中表示,并且可能发生资源 在历史记录列表中不止一次,所以处理历史记录捆绑包的服务器必须有一些策略来管理这一点。 当通过事务处理Bundle.entry.resource.id 时,具有POST请求方法的任何条目都必须使用 对于使引用得以保留的资源Bundle.entry.response.location

For other Bundle types, should the server choose to accept them, there will be no request element (note that every entry will have a resource). In this case, the server treats the entry as either a create or an update interaction, depending on whether it recognizes the identity of the resource - if the identity of the resource refers to a valid location on the server, it should treat it as an update to that location. Note: this option allows a client to delegate the matching process to the server. 对于其他捆绑类型,如果服务器选择接受它们,则 否request元素(请注意,每个条目都有一个资源)。 在这种情况下,服务器将条目视为创建或更新交互, 取决于它是否识别资源的标识-如果 资源引用服务器上的有效位置时,应将其视为 作为该位置的更新。注意:此选项允许客户端委托 与服务器的匹配进程。

The history interaction retrieves the history of either a particular resource, all resources of a given type, or all resources supported by the system. These three variations of the history interaction are performed by HTTP GET command as shown: 历史交互检索某个特定资源的历史,以及 给定类型或系统支持的所有资源。这三种历史变化 交互由httpgetcommand执行,如图所示

  GET [基地址]/[资源类型]/[id]/_history{?[参数]&_format=[mime-type]}
  GET [基地址]/[资源类型]/_history{?[参数]&_format=[mime-type]}
  GET [基地址]/_history{?[参数]&_format=[mime-type]}

The return content is a Bundle with type set to history containing the specified version history, sorted with oldest versions last, and including deleted resources. Each entry SHALL minimally contain at least one of: a resource which holds the resource as it is at the conclusion of the interaction, or a request with entry.request.method The request provides information about the result of the interaction that led to this new version, and allows, for instance, a subscriber system to differentiate between newly created resources and updates to existing resources. The principal reason a resource might be missing is that the resource was changed by some other channel rather than via the RESTful interface. If the entry.request.method is a PUT or a POST, the entry SHALL contain a resource. 返回内容是Bundlewith typeset tohistorycontaining the 指定的版本历史记录,最后按最旧版本排序,包括已删除的资源。 每个条目至少应包含以下内容之一:resourcewhich holds the resource as 它是在交互结束时,或者是一个requestwithentry.request.method request提供有关交互结果的信息, 导致了这个新版本,并允许,例如,订户系统 区分新创建的资源和现有资源的更新。主要原因Aresourcemay be missing 资源是由其他通道而不是通过RESTful接口更改的。如果 entry.request.methodputor apost方法

The interactions create, update, and delete create history entries. Other interactions do not (note that these operations may produce side-effects such as new AuditEvent resources; these are represented as create interactions in their own right). New resources or updates to existing resources that are triggered by operations also appear in the history, as do updates to the resources that result from interactions outside the scope of the RESTful interface. 交互createupdate,和delete 创建历史记录条目。其他交互作用不会(注意这些操作可能产生副作用 例如,新的AuditEvent资源;这些资源以自己的权利表示为创建交互)。 由操作触发的新资源或现有资源更新也显示在 历史记录,以及对资源的更新,这些资源是在 RESTful接口。

A HEAD request can also be used - see below. 支持HEAD请求 如下

A create interaction is represented in a history interaction in the following way: create在历史交互中以以下方式表示:

  <entry>
    <resource>
      <Patient>
        <!-- the id of the created resource -->
        <id value="23424"/>
        <!-- snip -->
      </Patient>
    </resource>
    <request>
      <!-- POST: this was a create -->
      <method value="POST"/>
      <url value="Patient"/>
    </request>
    <!-- response carries the instant the server processed the create -->
    <response>
      <lastModified value="2014-08-15T10:35:02.034Z"/>
    </response>
  </entry>

A delete interaction is represented in a history interaction in the following way: delete通过以下方式代表历史交互

  <entry>
    <!-- no resource included for a delete -->
    <request>
      <method value="DELETE"/>
      <url value="Patient/[id]"/>
    </request>
    <!-- response carries the instant the server processed the delete -->
    <response>
      <lastModified value="2014-08-20T11:05:34.174Z"/>
    </response>
  </entry>

Notes: 注意:

  • conditional creates, updates and deletes are converted to direct updates and deletes in a history list 条件创建、更新和删除在历史记录列表中转换为直接更新和删除
  • operations do not appear directly in the history log, but side effects (e.g. creation of audit logs. stored binaries, etc.) will appear where relevant 操作不会直接出现在历史记录日志中,而是副作用 (例如,创建审计日志。存储的二进制文件等)将出现在相关位置
  • The resource in the entry is the resource as processed by the server, not as submitted by the client (may be different) 条目中的资源是服务器处理的资源, 不是由客户提交的(可能不同
  • The server SHOULD populate at least response.lastModified so the time of processing is clear in the history record 服务器应至少填充 response.lastModified 因此,历史记录中的处理时间是明确的
  • Servers may choose to only record successful interactions. Servers may choose to only use 200 OK instead of other more specific success codes 服务器可以选择只记录成功的交互。 服务器可以选择只使用200 OK,而不是其他更具体的成功代码。
  • There may be more than one version of a given resource in the history 历史记录中给定资源可能有多个版本

In addition to the standard _format parameter, the parameters to this interaction may also include: 除了标准格式参数,此交互的参数还可能包括

_count : integer The maximum number of search results on a page, excluding related resources included by _include or _revinclude or OperationOutcomes. The server is not bound to return the number requested, but cannot return more 搜索结果的最大数目 在页面上,不包括由include或revienclude或operationoutcomes包含的相关资源。 服务器没有绑定返回请求的号码,但不能返回更多
_since : instant Only include resource versions that were created at or after the given instant in time 仅包括在给定即时时间或之后创建的资源版本
_at : date(Time) Only include resource versions that were current at some point during the time period specified in the date time value (see Search notes on date searching) 仅包括日期中指定时间段内某个时间点的当前资源版本 时间值(请参见搜索日期时的搜索注释
_list : reference Only include resource versions that are referenced in the specified list (current list references are allowed) 仅包括在指定的 列表(current list references被允许

Each of these parameters SHALL NOT appear more than once. 每个参数不得出现一次以上。

The history list can be restricted to a limited period by specifying a _since parameter which contains a full date time with time zone. Clients should be aware that due to timing imprecision, they may receive notifications of a resource update on the boundary instant more than once. Servers are not required to support a precision finer than by second. 历史记录列表可以通过指定一个包含完整日期时间和时区的以来的参数限制在有限的时间段内。 客户机应该知道,由于时间不精确,他们可能会多次收到边界即时资源更新的通知。服务器是 不需要支持比秒精细的精度。

The updates list can be long, so servers may use paging. If they do, they SHALL use the method described below for breaking the list into pages if appropriate, and respect the specified _count across pages. 更新列表可能很长,因此服务器可能使用分页。如果有,则应使用所述方法 如果合适的话,在下面将列表分为几页described below,并遵守指定的跨页计数。

The history interaction can be used to set up a subscription from one system to another, so that resources are synchronized between them. Refer to the Subscription resource for an alternate means of system synchronization. history交互可用于从一个系统设置订阅 使资源在它们之间同步。请参阅订阅资源 系统同步的另一种方法。

Additional Notes about maintaining a history of resources: 有关维护资源历史记录的附加说明:

  • The history is a record version history on a per-resource basis. It is not intended to support concurrent versions, or multi-branch version history 历史记录是基于每个资源的记录版本历史记录。它不是 旨在支持并发版本或多分支版本历史记录
  • Accordingly, there is no way to update or delete past versions of the record, except that the metadata can be modified (mainly for access control purposes) 因此,没有办法更新或删除记录的过去版本,除非 可以修改元数据(主要用于访问控制目的)
  • All past versions of a resource are considered to be superceded, and no longer active, but retained for audit/integrity purposes 资源的所有以前版本都被认为是被取代的,不再处于活动状态, 但出于审计/一致性目的保留
  • In the case that a past version of a resource needs to be explicitly documented as 'entered-in-error', use a Provenance resource pointing to the past version of the resource 如果资源的旧版本需要显式 记录为'entered-in-error',用provenance 指向资源的旧版本的资源
  • When tracing the history of a specific resource, applications should retrieve any provenance resources relating to the resource or its past versions 在跟踪特定资源的历史记录时,应用程序 应检索与资源相关的任何来源资源 或者它以前的版本
  • If a request is made for a history that is not available (e.g. the system does not keep a history for the type, or the particular instance), the server should return a 404 Not Found along with an OperationOutcome explaining the problem 如果对不可用的历史记录提出请求(例如,系统不为 类型或特定实例),服务器应返回404 Not Found和 operationoutcome解释问题

Thereis a caveat with the _list parameter, associated with changes to the list while making repeated periodic queries; if the list changes, the response will include changes to the resources in the list for the period specified, but will omit both later changes to items no longer in the list, or older changes associated with items in the list. This might not be a problem, but implementers should be aware of this issue. 对于与列表更改相关联的_list,有一个警告 在进行重复的定期查询时;如果列表发生更改,则响应将包括 对列表中指定期间的资源所做的更改,但稍后将忽略这两项 对列表中不再存在的项所做的更改,或与列表中的项关联的旧更改。 这可能不是一个问题,但是实现人员应该意识到这个问题

When processing create and update interactions, a FHIR server is not obliged to accept the entire resource as it is; when the resource is retrieved through a read interaction subsequently, the resource may be different. The difference may arise for several reasons: 处理时,createupdate 交互,fhir服务器没有义务接受整个资源 是;当通过read检索资源时 随后,资源可能会有所不同。两者之间可能存在差异 几个原因

  • The server merged updated content with existing content 服务器将更新的内容与现有内容合并
  • The server applied business rules and altered the content 服务器应用了业务规则并更改了内容
  • The server does not fully support all the features or possible values of the resource 服务器不完全支持资源的所有功能或可能的值

Note that there is no general-purpose method to make merging with existing content or altering the content by business rules safe or predictable - what is possible, safe and/or required is highly context dependent. These kinds of behaviors may be driven by security considerations. With regard to incomplete support, clients can consult the server's base CapabilityStatement profile references to determine which features or values the server does not support. 请注意,没有通用方法可以与现有内容或 根据安全或可预测的业务规则更改内容-什么是可能的, 安全和/或要求高度依赖于上下文。这些行为可能 出于安全考虑。对于不完全的支持,客户机可以查询服务器的 基础功能profile引用决定了 服务器不支持的值或特性。

The PATCH operation offers some support for making changes to a part of a resource and should be used where a client wishes to change just part of a resource, though transactional integrity issues are still important. PATCH operation 操作为对资源的一部分进行更改提供了一些支持,应该 在客户机希望仅更改部分资源的情况下使用,尽管事务完整性 问题仍然很重要。

To the degree that the server alters the resource for any of the 3 reasons above, the FHIR server will create implementation consequences for the eco-system that it is part of, which will need to be managed (i.e. it will cost more). For this reason, servers SHOULD change the resource as little as possible, given the constraints of the system exposing the FHIR resource. However due to the variability that exists within healthcare, this specification allows that servers MAY alter the resource on create/update. 服务器为任何 以上三个原因,fhir服务器将创建实现 对生态系统的影响 需要管理(即成本更高)。因此,服务器 考虑到限制条件,应该尽可能少地更改资源 暴露fhir资源的系统。然而,由于变化性 该规范允许服务器 可以在创建/更新时更改资源。

Similarly, to the degree that an implementation context makes special rules about merging content or altering the content, that context will become more expensive to maintain. 同样,在某种程度上,实现上下文使 有关合并内容或更改内容的规则,该上下文将 维护成本更高。

Although these rules are stated with regard to servers, a similar concept applies to clients - to the degree that different client systems interacting with the server do not support the same feature set, the clients and/or the server will be forced to implement custom logic to prevent information from being lost or corrupted. 尽管这些规则是关于服务器的,但是 概念适用于客户-在某种程度上不同的客户 与服务器交互的系统不支持相同的功能 设置,客户端和/或服务器将强制实现自定义 防止信息丢失或损坏的逻辑。

Some of these problems can be mitigated by following a pattern built on top of version-aware updates. In this pattern: 其中一些问题可以通过遵循一个模式来减轻 基于版本感知更新构建。在这种模式下:

  • The server provides a read interaction for any resource it accepts update interactions on 服务器为它接受的任何资源提供了一个read交互 update
  • Before updating, the client reads the latest version of the resource 更新之前,保证客户端 reads最新 资源的版本
  • The client applies the changes it wants to the resource, leaving other information intact (note the extension related rules around this) 客户端将其所需的更改应用于资源,并保留其他信息 完好无损(注意与extension related rules 扩展相关的规则)
  • The client writes the result back as an update interaction, and is able to handle a 409 or 412 response (usually by trying again) 客户机将结果写回一个update交互, 能够处理 409 or 412响应(通常通过再次尝试)

If clients follow this pattern, then information from other systems that they do not understand will be maintained through the update. 如果客户机遵循此模式,则来自其他系统的信息 他们不理解的内容将通过更新进行维护。

Note that it is possible for a server to choose to maintain the information that would be lost, but there is no defined way for a server to determine whether the client omitted the information because it wasn't supported (perhaps in this case) or whether it wishes to delete the information. 请注意,服务器可以选择维护 将丢失的信息,但没有定义的方法 用于确定客户端是否忽略信息的服务器 因为它不受支持(可能在本例中),或者 希望删除信息

Both client and server systems SHOULD clearly document how transaction integrity is handled, in the documentation in the CapabilityStatement. 客户机和服务器系统都应该清楚地记录事务处理的方式 完整性在CapabilityStatement的文档中处理。

Servers SHOULD support paging for the results of a search or history interaction, and if they do, they SHALL conform to this method (adapted from RFC 5005 (Feed Paging and Archiving) for sending continuation links to the client when returning a Bundle (e.g. with history and search). If the server does not do this then there is no way to continue paging. 服务器应支持对searchhistory交互的结果进行分页, 如果符合,则应符合该方法(改编自rfc 5005(feed 分页和存档)bundle (例如,使用historysearch)。如果服务器不这样做,那么就无法继续分页。

This example shows the third page of a search result: 此示例显示搜索结果的第三页:

<Bundle xmlns="http://hl7.org/fhir">
  <!-- snip metadata -->
  <!-- This Search url starts with base search, and adds the effective
    parameters, and additional parameters for search state. All searches
    SHALL return this value.

	  In this case, the search continuation method is that the server
    maintains a state, with page references into the stateful list.
	-->
  <link>
    <relation value="self">
    <url value="http://example.org/Patient?name=peter&stateid=23&page=3"/>
  </link>
  <!-- 4 links for navigation in the search. All of these are optional, but recommended -->

  <link>
    <relation value="first"/>
    <url value="http://example.org/Patient?name=peter&stateid=23&page=1"/>
  </link>
  <link>
    <relation value="previous"/>
    <url value="http://example.org/Patient?name=peter&stateid=23&page=2"/>
  </link>
  <link>
    <relation value="next"/>
    <url value="http://example.org/Patient?name=peter&stateid=23&page=4"/>
  </link>
  <link>
    <relation value="last"/>
    <url value="http://example.org/Patient?name=peter&stateid=23&page=26"/>
  </link>

  <!-- then the search results... -->
</Bundle>

The links are opaque to the client, have no dictated structure, and only the server understands them. The client must use the server supplied links in order to traverse the pages. A server MAY add additional state tracking parameters to the links, as shown in the example above, though the server need not use a stateful paging method as shown in this example - it is at the discretion of the server how to best ensure that the continuation retains integrity in the context of ongoing changes to the resources. An alternative approach is to use version specific references to the records on the boundaries, but this is subject to continuity failures when records are updated. 链接对客户端是不透明的,没有指定的结构,只有 服务器理解它们。客户端必须按顺序使用服务器提供的链接 浏览页面。 服务器可以向链接添加额外的状态跟踪参数,如上面的示例所示, 尽管服务器不需要使用如本例所示的有状态分页方法,但它位于 服务器决定如何最好地确保延续在 正在对资源进行更改的上下文。另一种方法是使用版本 对边界记录的特定引用,但这取决于连续性。 更新记录时失败。

A server MAY inform the client of the total number of resources returned by the interaction for which the results are paged using the Bundle.total. 服务器可以通知客户机交互返回的资源总数,并为其分页结果。 使用Bundle.total

Note that for search, where _include can be used to return additional related resources, the total number of resources in the feed may exceed the number indicated in totalResults. 请注意,对于搜索,其中include可用于返回其他相关资源,总数 源中的资源可能超过totalresults中指示的数量。

In the case of a search, the initial request may be made via a POST, but the follow up page requests will be made via GET requests. However servers SHOULD allow for a client to convert the follow up requests to be made via a POST. 在search的情况下,可以通过post发出初始请求,但是 后续页面请求将通过GET请求进行。但是,服务器应该允许 客户机转换通过POST发出的后续请求。

Anywhere that a GET request can be used, a HEAD request is also allowed. HEAD requests are treated as specified in HTTP: same response as a GET, but with no body. 在任何可以使用GET请求的地方,也允许HEAD请求。头请求被视为 在HTTP中指定:与get的响应相同,但没有主体。

Servers that do not support HEAD MUST respond in accordance with the HTTP specification, for example using a 405 ("method not allowed") or a 501 ("not implemented"). 不支持head的服务器必须按照HTTP规范响应, 例如,使用405(“方法不允许”)或501(“未实现”)

This specification defines or recommends some custom headers that implementers can use to assist with deployment/debugging purposes: 本规范定义或推荐了一些实现者 可用于协助部署/调试目的:

X-Request-IdA unique id to for the request/response assigned by either client or server. Request: assigned by the client. Response: assigned by the server 客户机或服务器为请求/响应分配的唯一ID。请求: 由客户指定。响应:由服务器分配
X-Correlation-IdA client assigned request id echoed back in the response 客户机分配的请求ID在响应中回显。
X-Forwarded-ForIdentifies the originating IP address of a client to an intermediary 标识客户端到中介的原始IP地址
X-Forwarded-HostIdentifies the original host requested by the client in the Host HTTP request header 标明在HTTP请求头的客户端的原始的主机请求
X-IntermediaryStamped by an active intermediary that changes the request or the response to alter it's content (see below) 由更改请求或响应以更改其内容的活动中介盖章(见下文)

The request id in X-Request-Id is purely to help connect between requests and logs/audit trails. The client can assign an id to the request, and send that in the X-Request-Id header. The server can either use that id or assign it's own, which it returns as the X-Request-Id header in the response. When the server assigned id is different to the client assigned id, the server SHOULD also return the X-Correlation-Id header with the client's original id in it. x-request-id中的请求id纯粹是帮助连接 请求和日志/审计跟踪。客户机可以为请求分配一个ID, 并将其发送到x-request-id头中。服务器可以使用 ID或分配它自己的,它返回为x-request-idheader 在回应中。当服务器分配的ID与 客户端分配的ID,服务器还应返回x-correlation-id 包含客户端原始ID的头。

The HTTP protocol may be routed through an HTTP proxy (e.g. as squid). Such proxies are transparent to the applications, though implementers should be alert to the effects of caching, particularly including the risk of receiving stale content. See the HTTP specification for further detail HTTP协议可以通过HTTP代理(如Squid)进行路由。 这些代理对应用程序是透明的,尽管实现者 应该警惕缓存的影响,特别是包括 接收过时内容的风险。请参阅 http规范 了解更多详细信息

Interface engines may also be placed between the consumer and the provider. These differ from proxies because they actively alter the content and/or destination of the HTTP exchange and are not bound by the rules that apply to HTTP proxies. Such agents are allowed, but SHALL mark the request with an X-Intermediary header to assist with debugging/troubleshooting. Any agent that modifies an HTTP request or response content other than under the rules for HTTP proxies SHALL add a stamp to the HTTP headers like this: 接口引擎也可以放置在使用者和 提供程序。这些不同于代理,因为它们是主动的 更改HTTP交换的内容和/或目标,并且 不受应用于HTTP代理的规则的约束。允许使用此类代理, 但应将请求标记为X-中间标题以协助 调试/故障排除。修改HTTP请求或 HTTP代理规则以外的响应内容应增加 HTTP的标记 标题如下:

  X-Intermediary : [identity - usually a FQDN]

End point systems SHALL NOT use this header for any purpose. Its aim is to assist with system troubleshooting. 端点系统不得将该头用于任何目的。其目的 协助系统故障排除。

These tables present a summary of the interactions described here. Note that all requests may include an optional Accept header to indicate the format used for the response (this is even true for DELETE since an OperationOutcome may be returned). 这些表概述了这里描述的交互作用。 请注意,allrequests may include an optionalacceptheader to indicate the format used 对于响应(对于delete,这甚至是正确的,因为可能会返回operationoutcome)

Interaction PathRequest
Verb Content-Type Body Prefer Conditional
read /[type]/[id] GET N/A N/A N/A O: ETag, If-Modified-Since, If-None-Match
vread /[type]/[id]/_history/[版本号] GET N/A N/A N/A N/A
update /[type]/[id] PUT R Resource O O: If-Match
patch /[type]/[id] PATCH R (may be a patch type) Patch O O: If-Match
delete /[type]/[id] DELETE N/A N/A N/A N/A
create /[type] POST R Resource O O: If-None-Exist
search /[type]? GET N/A N/A N/A N/A
/[type]/_search? POST application/x-www-form-urlencoded form data N/A N/A
search-all ? GET N/A N/A N/A N/A
capabilities /metadata GET N/A N/A N/A N/A
transaction / POST R Bundle O N/A
history /[type]/[id]/_history GET N/A N/A N/A N/A
history-type /[type]/_history GET N/A N/A N/A N/A
history-all /_history GET N/A N/A N/A N/A
(operation) /$[name], /[type]/$[name] or /[type]/[id]/$[name] POST R ParametersN/A N/A
GET N/A N/A N/A N/A
POST application/x-www-form-urlencoded form data N/A N/A

Notes:

  • N/A = not present, R = Required, O = optional N/A = 无要求, R = 必填, O = 可选项
  • For operations defined on all resources, including direct access to the meta element, see Resource Operations 有关在所有资源上定义的操作,包括直接访问元元素,请参 阅资源操作
InteractionResponse
Content-Type Body Location Versioning Status Codes
read R R: Resource N/A R: ETag, Last-Modified 200, 404, 410
vread R R: Resource N/A R: ETag, Last-Modified 200, 404
update R if body O: Resource (Prefer) N/A R: ETag, Last-Modified 200, 201, 400, 404, 405, 409, 412, 422
patch R if body O: Resource (Prefer) N/A R: ETag, Last-Modified 200, 201, 400, 404, 405, 409, 412, 422
delete R if bodyO: OperationOutcome N/A N/A 200, 202, 204, 404, 405, 409, 412
create R if body O : Resource (Prefer) R R: ETag, Last-Modified 201, 400, 404, 405, 422
search R R: Bundle N/A N/A 200, 401?
search-all R R: Bundle N/A N/A 200, 401?
capabilities R R: CapabilityStatementN/A N/A 200, 404
transaction R R: Bundle N/A N/A 200, 400, 404, 405, 409, 412, 422
history R R: Bundle N/A N/A 200
history-type R R: Bundle N/A N/A 200
history-all R R: Bundle N/A N/A 200
(operation) R R: Parameters/ResourceN/A N/A 200

Note: this table lists the status codes described here, but other status codes are possible as described by the HTTP specification. Additional codes that are likely are server errors and various codes associated with authentication protocols. The security page notes several security related issues that may impact which codes to return. 注意:此表列出了此处描述的状态代码,但HTTP规范中描述的其他状态代码是可能的。 其他代码可能是服务器错误和与身份验证协议相关的各种代码。安全页面 注意到一些可能影响返回代码的安全相关问题。