首页 论坛 FHIR专题 FHIR资料翻译 HL7 Fhir RESTful API

标签: 

该话题包含 0 个回复,有 1 个参与人,并且由  admin1 年, 5 月 前 最后一次更新。

正在查看 1 帖子:1-1 (共 1 个帖子)
  • 作者
    帖子
  • #194

    admin
    管理员

    Hl7 Fhir Restful API

    翻译来源:http://hl7.org/fhir/http.html

    由于大部分采用直译,不妥之处希望大家提出异议共同完善

    2.21.0 RESTful API

    Fhir基础架构工作组

    成熟度: 1

    状态: 试用

    此规范基于REST术语的常见行业级使用的“RESTful”规范。在实践中,尽管通过使用扩展完全可以达到三级,但当前只支持到REST成熟度模型的二级作为核心规范的一部分。由于FHIR是一个依赖于标准化的资源结构和接口的标准。因此,这可能被认为是违反REST原则,但它却是可以确保跨系统一致性互操作的关键。 每个资源类型具有定义的相同交互集,可用于以高度细粒度的方式管理资源。声称符合本框架要求符合“RESTful FHIR”一致性)。 请注意,在此RESTful框架中,使用HTTP请求/响应 直接在服务器资源上执行事务。API不直接解决认证,授权和审核收集工作. – 有关更多信息,请参阅安全页面.

    API描述的是对类型管理数据集合中的单个资源一系列操作(称为交互)。服务器可以选择使用哪些交互操作,以及他们支持哪些资源类型。服务器可提供一个支持哪些交互和资源的能力说明( Capability
    Statement
    )

    以下是逻辑交互的定义:

    实例级互动

     

    read

    读取当前最新的资源

    vread

    阅读资源的特定版本

    update

    根据其ID来更新现有资源(如果是新的,则创建它)

    patch

    (补丁)通过发布一组数据来更新现有资源

    delete

    删除资源

    history

    检索特定资源的更改历史记录

    类型级互动

    create

    创建一个服务器分配ID的新资源

    search

    根据一些过滤条件搜索资源类型

    history

    检索特定资源类型的更改历史记录

    全系统互动

    capabilities

    获取系统能力语句

    batch/transaction

    在单个交互中更新,创建或删除一组资源

    history

    检索所有资源的更改历史记录

    search

    根据一些过滤条件搜索所有资源类型

    除了这些交互之外,还有一个操作框架,其中包括端点的验证

    格式风格规范

    此页面交互的定义如下:

    VERB [base]/[type]/[id] {?_format=[mime-type]}

    · 第一个单词VERB是用于交互的HTTP 动词

    · [] 中的内容是必选的, 内容可替换.可能的内容包括:

    o    base: Service
    Base URL

    o    mime-type: Mime
    Type
    (多媒体格式类别)

    o    type: 资源类型的名字 (患者“)

    o    id: 资源的逻辑编号 LogicID

    o    vid: 资源的版本号 VersionID

    o    compartment: 隔间(可能是数据资源再分组)名称

    o    parameters: 为特定交互定义的URL参数

    · {} 代表内容可选

    使用这些模式构建URL的实现应符合ARFC 39866节附录A ,它需要对URL中偶尔出现的许多字符进行百分号编码(转意)(主要是搜索参数)。

    本规范使用下划线作为前缀,以区分其他名称中的保留名称,以下是3种情况案例:

    · To differentiate system wide history and search interactions
    from interactions on Resource Types

    · 区分对于资源类型交互的历史和搜索

    • To differentiate search, history
      and similar interactions from instances of a resource type

    · 区分对于资源类型实例的搜索,历史和类似的交互

    • To differentiate search
      parameters defined for all resources from those defined for specific
      resource types

    · 区分对于特定的资源类型的搜索参数定义

    此外,该字符$用作操作名称的前缀,这些名称是由本规范或实现者定义的基本API的类似RPC添加。

    2.21.0.1 基于URL的服务

    基于URL的服务,是在所有通过找到的界面定义的资源的地址。基于URL的服务采用以下形式

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

    路径部分是可选的 , 不包括尾部斜线. 本规范中定义的每种资源类型都有一个管理者(或实体集 它位于资源类型名称/[type]所在的位置。例如, Patient 就是:

    所有逻辑交互都是相对于服务根URL定义的。这意味着如果已知系统上的任何一个FHIR资源的地址,就可以确定其他资源的地址。

    注意:本规范定义的所有URL(和构成URL一部分的ids)区分大小写。客户端应该使用UTF-8URL进行编码,服务器应该对其进行解码,假设它们是UTF-8(对于背景,请参阅此处 此处 )。

    注意,服务器可能会使用这种形式的路径,http://server/…[xx]…其中的[xx]某个变量部分标识了FHIR API的特定实例。通常,变量id标识病人或用户,底层信息完全由与之关联的逻辑身份隔开[xx]。在这种情况下,FHIR API以病人或用户为中心的视图呈现记录,其中认证/授权被明确地授予URL,理由是某些可识别用户与逻辑身份相关联。没有必要在URL中明确地嵌入患者ID – 实现可以通过使用OAuth登录将FHIR终点与特定患者或提供者相关联。请参阅隔间的逻辑支撑。

    标识

    系统通常需要比较两个URL来确定它们是否引用相同的底层对象。为本说明它,采用以下规则:

    · 网址的查询部分(?后面的任何内容)都将被忽略

    · URL的文档部分(即:不包括服务器/端口)的比较是区分大小写的

    · http:https协议:不适用于不同的底层对象

    · 如果指定了端口,则端口必须相同或对象不同(由于端口映射和/或在不同端口上运行的接口引擎的流行)。端口只有在对服务器有明确含义时才应该是明确的

    例如: http://myserver.com/Patient/1  https://myserver.com/Patient/1 指的是内涵相同对象,而http://myserver.com:81/Patient/1 是区别于上述的一个独立的实体。这并不意味着这两个地址需要被同等对待。

    2.21.0.2 资源元数据和版本控制

    每个资源都有一组相关的资源元数据元素. 这些映射到HTTP请求和响应使用以下字段:

    元数据项

    Where found in HTTP

    Logical
    Id (.id)

    IDURL中有明确表示

    Version
    Id (.meta.versionId)

    版本号在 ETag 头信息中体现

    Last
    modified (.meta.lastUpdated)

    HTTP Last-Modified (Header)头信息

    请注意,版本ID被认为是ETagETag 标题应以前缀W/ 和引号括起来,例如:

    ETag: W/”3141″

    2.21.0.3 安全

    使用HTTPS是可选的,但所有医疗保健数据的生产交换应适当使用SSL和额外的安全性。有关详细信息,请参阅HTTP Security。大多数操作将需要用户身份验证,并且所有执行RBAC/ABAC的操作,以及某些操作可能取决于授予的适当同意。

    请参阅关于如何处理访问拒绝响应的 HTTP安全性

    注意:为了支持基于浏览器的客户端应用程序,服务器应该为这里记录的交互实现跨原始资源共享。经验表明,这是一个可持续发展的问题的领域,因为安全漏洞被持续发现和关闭。

    2.21.0.4 HTTP状态码

    在特定情况下,本规范制定了特定HTTP状态代码的使用规则,其中状态代码可以正确地映射到特定状态,并且仅在正确的状态代码不明显的情况下。其他HTTP状态码可以适用于其他状态,特别是包括各种认证相关的状态码和重定向。认证重定向不应被解释为改变资源本身的位置(常见的Web编程错误)。

    FHIR定义了一个OperationOutcome
    resource
    ,可用于传达具体的可处理错误信息。对于某些交互和特定返回码的组合,需要将OperationOutcome作为响应的内容返回。OperationOutcome可能返回任何带有 HTTP 4xx or 5xx 码的响应,但这不是必需的这些错误中的许多可能是由FHIR服务器基础的通用服务器框架生成的。

    2.21.0.5 管理返回的内容

    本章节的关注点在于如何解约带宽问题,该规范指的是允许客户端返回特定的内容。

    2.21.0.5.1 条件读取

    客户端使用If-Modified-Since, If-None-Match HTTP 来读取响应,如果是这样,他们应该接受” 304未修改作为响应的有效状态代码(这意味着内容自该日期起不变)或完整内容(内容已更改,或服务器不支持条件请求)。

    服务器可以返回304(未修改)的状态码, 因为自从  If-Modified-Since 日期时间  被指定If-None-Match 的内容从未改变过,或者它们可以正常的返回全部内容。这种优化在减少缓存带宽方面是有实质作用的,尽量让服务器来支持此功能,但不是必须的。如果服务器不支持条件读取,则可以只返回完整的内容。

    2.21.0.5.2 建立/更新/补丁/事物

    这些交互是使用POSTPUTPATCH来完成的,服务器仅返回状态代码是可以的,或者返回创建或更新后的整个结果资源(可能与客户端提交的不同) )。在事务处理的情况下,将返回一个带有很多 (entry)实例的数据集合(Budle.entry.reponse),而不是Bundle.entry.response值。

    客户端可以使用 HTTP返回首选项  HTTP return
    preference 
    表明是否返回整个资源:

    Prefer: return=minimal
    Prefer: return=representation
    Prefer: return=OperationOutcome

    第一个要求不返回数据体(body)。第二个要求返回完整的资源。第三个请求服务器返回一个OperationOutcome 资源,其中包含有关操作的提示和警告,而不是完整的资源。服务器应该尊重这个请求头。在没有这个标题头的情况下,服务器可以选择是否返回完整资源(但不是OperationOutcome;只有在明确请求时才应该返回)。请注意,此设置仅适用于成功的交互。在出现故障的情况下,服务器应始终返回包含OperationOutcome资源的正文。

    2.21.0.6 内容类型和编码

    FHIR资源的正式MIME类型是application/fhir+xmlapplication/fhir+json。客户端和服务器将使用正确的MIME类型:

    · XML: application/fhir+xml

    · JSON: application/fhir+json

    · RDF: text/turtle (only the Turtle format
    is supported)

    服务器应支持服务器驱动的内容协商,如 HTTP规范第12( section
    12 
     )所述。

    注意:在FHIR DSTU2STU3之间,正确的mime类型从application/xml+fhir和更改application/json+fhirapplication/fhir+xmlapplication/fhir+json。服务器也可以支持较老的mime类型,并鼓励这样做来平滑传输过程。

    .

    为了支持各种接口应用的限制,服务器应该通过支持可选的 _format 参数 来替代MIME类型指定响应格式。当它由于内部限制无法正确设置(例如:Xslt 语言), 此参数允许客户端重写 accept 信息头(Header)的值。对于 _format 参数, xml, text/xml, application/xml, application/fhir+xml 应理解为XML格式,代码jsonapplication/json application/fhir+json将被理解为JSON格式,代码 <span lang="EN-US">ttl</span>  <span lang="EN-US">text/turtle</span>应理解为 turtle RDF格式。此外,允许使用 htmltext/html 格式。

    注意:该_format参数不覆盖content-type头信息。

    提交search请求时可以被接受这个application/x-www-form-urlencoded 内容类型。

    如果没有指定accept标头和_format参数,服务器返回的内容的MIME类型是未定义的,可能会有所不同。

    使用注意:如果客户端在Accept标头(application / xmltext /
    json
    application / json)中提供通用的MIME类型,服务器应使用本规范中描述的XMLJSON格式作为最佳的MIME命名表达类型。(不用在意这个注释 note on
    the Binary resource
    )。

    2.21.0.7版本支持

    服务器API应提供对版本控制的完全支持,即对versionId正确填写和跟踪 ,支持 vread方式读取和实现版本感知更新。支持相关系统可以跟踪到正确的信息版本,并保持临床记录的完整性。然而,目前的许多操作系统并没有这样做,也不能轻易地重新设计。

    因此,允许不提供版本控制支持的服务器和不强制执行版本控制API的服务器。客户可以选择只提供完整信息(当前最新的数据)模式来进行交互。系统在其能力声明中声明对版本控制支持的程度,需要指明版本控制支持的三个级别之一:

    · no-version: 版本控制和 meta.version 不支持(服务器)或 使用(客户端)

    · versioned: 版本控制和 meta.version 支持(服务器)或 使用(客户端)

    · versioned-update: 版本控制和 meta.version 并且使用版本感知更新对于服务器更新时版本ID必须是正确的,客户端需要特别指定特定的(If-match header)信息头。

    服务器应始终 使用Date
    header
    返回HTTP Response标头中日期搜索的默认时区。注意:服务器不需要具有默认时区。

    2.21.0.8 读取

      GET [base]/[type]/[id] {?_summary=text}

    The read  指的是访问资源的当前(最新)内容。交互由HTTP GET 命令执行,如图所示:

    GET [base]/[type]/[id] {?_format=[mime-type]}

    这将返回指定的资源类型内容的单个最新的当前实例。浏览器可能访问此网址。id 的值类型在 id type 有所书名,  返回的资源中应该有[id]一个元素的值为上面语句中的id值。服务器应该返回ETag带有该资源的versionId(如果支持版本控制)和一个Last-Modified标题的标头。

    注意:未知资源和已删除的资源在读取时的处理方式不同:一个 GET对于已删除的资源返回410状态代码,而GET对于未知资源则返回 404状态代码。不能追踪已删除记录的系统会将已删除的记录视为未知资源。由于已删除的资源可以恢复生效,当读取删除已经恢复的资源记录时,服务器会在错误响应中包含一个带有versionId ETag,以便管理版本冲突。

    另外,_summary在读取资源时可以使用搜索参数:

    GET [base]/[type]/[id] {?_summary=text}

    这个例子就是要求返回资源内容的子集,作为指定的_summary参数,它可能是 truefalsetextdata值。请注意,仅包含数据子集的资源不适合用作更新资源的基础,也不适用于其他用途。同样_elements参数也同_summary一样。但是服务器应该被支持此操作(资源子集)。服务器应该定义一个带有作为一个简单标签( Simple
    Tag
    )子集( SUBSETTED)的 Resource.meta.tag 明确标注这些资源。(参照 Search 文档中的 关于对_Summary 的说明)

    2.21.0.9 vread

    vread是对特定版本(VersionId)的读取。交互由HTTP GET命令执行,如图所示:

    GET [base]/[type]/[id]/_history/[vid] {?_format=[mime-type]}

    这将返回指定具体versionId的资源类型内容的单个实例。返回的资源应该有带有id的元素和一个带有vid meta.versionId。服务器应该返回一个带有versionId 的标头的ETag(如果支持版本控制)和一个 <span lang="EN-US">Last-Modified </span><span style="font-family: arial;">头信息</span>

    版本编号(“VID”)是一个作为 Logical Id 符合格式要求的不透明(不明确显示)标识。它可以通过执行历史交互可见(见下文),可以通过从read内容模型中从或从版本特定引用返回的内容位置记录版本ID来找到该id 。如果引用的版本实际上是资源被删除的资源,则服务器应该返回410状态码。

    鼓励服务器支持对当前版本的资源进行版本检测,即使它们不提供对先前版本的访问。如果对先前版本的资源提出请求,并且服务器不支持访问以前的版本(通常是或针对该特定资源),则应返回” 404未找到错误,其操作结果说明历史不是支持基础资源类型或实例。

    2.21.0.10 更新

    如果服务器上没有给定ID的资源,更新操作会建立一个新版本的资源。更新资源的命令符如下所示:

    PUT [base]/[type]/[id] {?_format=[mime-type]}

    请求更新的数据主体中的数据应该是一个具有与URL 中的type/id相同值的元素。如果没有提供元素,或者该值是不相等,则服务器应该使用HTTP 400的错误代码,并且应该提供一个问题的描述(OperationOutcome)。如果请求体包含一个 meta ,则服务器应忽略提供的versionid lastupdated 值。如果服务器支持版本控制,它将填充并使用新的正确值。允许服务器检查和更改其他元数据值,但应避免这样做(请参阅元数据描述id[id]id400metaversionIdlastUpdatedmeta.versionIdmeta.lastUpdated了解更多信息)。请注意,不支持更新过去的版本请参阅有关历史记录交互的注释。

    服务器应接受接收更新时提交的资源,并在后续读取时返回相同的内容。但系统可能无法做到这一点; 请参阅有关交易完整性的说明。另外,有关更新行为的更多讨论,请参阅提交的数据和取回数据之间的变化(Variations between
    Submitted data and Retrieved data
    )。请注意,update通常会更新资源的整个内容。部分更新请参见patch下文。

    如果交互成功,则服务器将返回OK HTTP状态代码200表明如果资源已更新,或者是201表明已创建,同时返Etag信息(versionId Last-Modified)。如果资源被创建(即,交互结果201创建状态),则服务器应该返回一个Location头(这是为了HTTP符合;否则不需要)。

    注意:服务器可能会选择在接受更新时保留XML注释,说明和格式化或JSON空格,但不需要这样做。对数字签名的影响可能需要考虑。

    请注意:服务器可能选择允许客户端将PUT资源提交到服务器上尚不存在的位置 ,或者允许客户端定义资源的ID。服务器是否允许这种基于与客户端关系性质的部署选择。然而许多服务器不允许客户端定义其ID,但是在某些配置中可能需要,原因如下:

    1、客户机正在复制服务器上的现有数据模型,并且需要保留原始ID以保持持续的完整性。 2、客户端是一个基于pushpub / sub的服务器(客户机是一个基于推送的服务器/子服务器)(这是一个特殊情况的第一个原因) 3、多个客户机在约定数据模型上下文中的共享服务器之间共享的多个服务器共享的进行推送 另外,客户端可以共享未出现冲突的商定的识别模型(例如密钥服务器,范围标识符或UUID)。

    服务器可以选择是否支持客户端定义的ID,并使用CapabilityStatement.rest.resource.updateCreate向客户端指示。

    2.21.0.10.1 拒绝更新

    允许服务器由于完整性问题或其他业务规则而拒绝更新交互,并相应地返回HTTP状态代码(通常为422)

    FHIR相关的错误返回的常见HTTP状态代码(除了与安全性,标头和内容类型协商问题相关的正常HTTP错误):

    · 400 Bad Request无法解析资源或失败的基本FHIR验证规则(或找到条件条件的多个匹配)

    · 401 Not Authorized所尝试的交互需要授权

    · 404 Not Found不支持资源类型,或不支持FHIR端点

    · 405 Method Not allowed在更新之前资源不存在,并且服务器不允许客户端定义的ids

    · 409/412版本冲突管理见下文

    · 422 Unprocessable Entity提议的资源违反了适用的FHIR配置文件或服务器业务规则

    任何这些错误都应附有一个OperationOutcome资源,提供有关该问题的其他详细信息。

    有关处理更新时系统可能表现的其他信息,请参阅提交的数据和检索的数据页面之间的变化。

    2.21.0.10.2 条件更新

    条件更新交互允许客户端基于url 中的搜索参数而不是逻辑ID去更新现有资源 。要完成此操作,客户端可以使用如下所示的PUT

    PUT [base]/[type]?[search parameters]

    当服务器处理此更新时,它将使用其资源类型的标准搜索参数执行搜索,服务器如何处理取决于搜索参数返回的具体记录数量:

    · No matches: 服务器执行create交互

    · One Match: 服务器根据匹配的资源执行更新

    · Multiple matches:服务器返回一个 412 前提条件失败错误,指出客户端的搜索条件不充分

    这种变体的更新方法可用于无状态客户端(如接口引擎)将更新的结果提交给服务器,而无需记住服务器分配的逻辑ID。例如,从初步最终更新实验室状态的客户端可能会使用最终结果提交PUT
    path/Observation?identifier=http://my-lab-system|123

    请注意,事务和条件创建/更新/删除是复杂的交互,并不期望每个服务器都将实现它们。不支持条件更新的服务器应返回HTTP 400 error and an OperationOutcome.

    2.21.0.11 管理资源冲突

    Lost Updates  ,其中两个客户端同时更新相同的资源,第二个会覆盖第一个更新,可以使用ETag If-Match头的组合来防止。这也被称为乐观锁定

    为了支持此用法,服务器应始终返回带有ETag资源:

    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

    如果提供了Etag version ID应该与资源的版本号的值相匹配。服务器会生成合法有效的版本ID,并且在同一资源的所有版本的地址空间内是唯一的。当资源作为bundle的一部分返回时,如果不存在ETag,资源的versionId可以直接使用。

    如果客户端希望请求一个具有版本感知更新,它将使用If-Match从服务器引用ETag 的头文件提交请求

    PUT
    /Patient/347 HTTP/1.1

    If-Match:
    W/”23″

    如果If-Match标题中给出的版本ID不匹配,则服务器返回409
    Conflict
    状态代码,不更新资源。

    服务器可以要求客户端 在找不到标题时If-Match返回412 Pre-condition
    failed
    状态码来提供标If-Match头。

    2.21.0.12 补丁

    作为更新整个资源的替代方法,客户端可以执行补丁操作。当客户端尝试最小化其带宽利用率时,或在客户端仅部分访问资源或对资源的支持的情况下,这将非常有用。该PATCH 相互作用由HTTP执行PATCH命令如下所示:

    PATCH [base]/[type]/[id] {?_format=[mime-type]}

    PATCH操作的主体应该是:

    · a JSON Patch 文档包含 application/json-patch+json

    · an XML Patch 文档包含 application/xml-patch+xml

    · FHIR
    Content Type
    FHIRPath
    Patch
    参数资源

    在任何情况下,服务器应按照指定的格式处理资源的副本,并按照指定的格式操作文档。当操作全部处理完毕后,服务器会将生成的文档作为Update 操作进行处理; 所有版本和错误处理等都适用于指定的,  Prefer
    Header
    处理PATCH操作可能引起比较强的版本敏感性。因此,服务器应支持条件的PATCH,它应该与并发管理(Concurrency
    Management
    )中的更新所规定的一致。客户端应始终考虑使用特定于版本的PATCH操作,以便不执行不当的操作。此外,服务器应支持条件PATCH,其工作原理与条件更新所述相同。 在执行PATCH操作后,服务器应确保资源中的叙述在临床表达上是安全的。如何准确的定义依赖于文档的上下文内容,如何维护叙述性的内容,服务器可能要考虑以下因素:

    · 如果现有的叙述具有状态!= generated,则服务器可以拒绝PATCH操作

    · 一旦将操作应用于数据,服务器就可以重新生成叙述

    · 在有限的情况下,XML PATCH操作可以更新叙述

    · 服务器可以删除叙述,因为后来的一些过程将能够正确填写

    处理XML修补程序文档是因为命名空间处理而棘手。服务器应正确处理命名空间,但请注意,FHIR资源只包含两个XML命名空间,用于FHIRhttp://hl7.org/fhir)和XHTMLhttp://www.w3.org/1999/xhtml)。 对于PATCH示例,请参阅(链接到)。 补丁操作可以使用FHIRPath补丁格式作为批处理或事务操作的一部分执行。

    2.21.0.13 删除

    delete 删除现有资源。交互由HTTP DELETE命令执行,如图所示:

    DELETE [base]/[type]/[id]

    删除操作意味着资源中后续非特定版本读取将返回410HTTP状态代码,并且通过搜索查询操作将不再发现该资源。成功删除后,或是资源完全不存在时,再次执行删除操作服务器应该返回200 OK,或者204 No Content

    根据在其上下文中应用的业务规则,是否支持删除特定资源类型或特定实例是由服务器自行决定的。如果服务器拒绝将该类型的资源作为一个整体策略删除,则应返回” 405 不允许的方法状态代码。如果由于资源特有的原因(如引用完整性),服务器拒绝删除资源,则应返回409冲突。已经被删除的资源可以通过后续的update 使用HTTP PUT 来恢复。

     

    许多资源具有与删除思想重叠的状态元素。每个资源类型定义了删除交互的语义。如果没有提供文档,删除交互应该被理解为删除资源的记录,而不涉及隐含的真实相关资源的状态。 对于维护版本历史记录的服务器,delete交互不会删除资源的版本历史记录。从版本历史的角度来看,删除资源相当于创建一个没有内容并被标记为已删除的特殊类型的历史记录条目。请注意,不支持删除过去的版本请参阅历史记录交互的注释。 由于删除的资源可能会恢复生效,服务器可能会ETag在删除响应中包含一个,以便在资源恢复使用时允许版本争用管理。

    2.21.0.13.1 有条件的删除

    条件删除交互允许客户端基于某些选择条件标准而不是特定的逻辑ID删除现有资源。为了实现这一点,客户端发出HTTP DELETE,如图所示:

    DELETE [base]/[type]/?[search parameters]

    当服务器处理此删除时,它将使用资源类型的标准搜索工具执行搜索 。它采取的行动取决于找到了几个匹配:

    · No matches or One Match:服务器delete在匹配资源上执行普通操作

    · Multiple matches: 服务器可以选择删除所有匹配的资源,或者可以选择返回一个412前提条件失败的错误,指出客户端的选择的条件不充分。服务器指示是否可以在其能力声明(.rest.resource.conditionalDelete)中是否可以删除多个资源。如果有多个匹配,则必须全部删除,否则服务器将返回错误。

    此变体可用于无状态客户端(如接口引擎)删除服务器上的资源,而无需记住服务器分配的逻辑ID。例如,客户端删除实验室原子结果可能会删除资源DELETE
    /Observation?identifier=http://my-lab-system|123

    请注意,事务和条件创建/更新/删除是复杂的交互,并不期望每个服务器都将实现它们。不支持条件删除的服务器应返回HTTP 400错误和OperationOutcome

    2.21.0.14 创建

    create 互动中创建一个服务器分配的位置的新资源。如果客户端希望控制新提交的资源的ID,则应该使用更新 交互。该create相互作用由HTTP执行POST命令如下所示:

    POST [base]/[type] {?_format=[mime-type]}

    请求机构应为FHIR资源。资源不需要一个id元素(这是资源不存在id元素的少数情况之一)。如果id提供了一个,则服务器将忽略它。如果请求主体包含元数据,服务器将忽略现有值versionIdlastUpdated值。服务器应填充idmeta.versionId meta.lastUpdated 用新的正确的价值观。允许服务器查看和更改其他元数据值,但应避免这样做(有关更多信息,请参阅元数据描述)

    服务器应该接受接收创建时提交的资源,并在随后读取时返回相同的内容。但是有些系统可能无法做到这一点; 请参阅有关交易完整性的说明进行讨论。

    服务器返回201创建的HTTP状态代码,并且还返回一个Location包含创建的资源版本的新的逻辑ID和版本号的头:

    Location: [base]/[type]/[id]/_history/[vid]

    在哪里[id][vid]是资源版本的新创建的id和版本号。服务器应该返回一个ETag标题 versionId (如果版本支持)和一个Last-Modified标题。

    当资源语法或数据不正确或无效,并且不能用于创建新资源时,服务器返回400错误请求HTTP状态代码。当服务器由于业务规则拒绝资源的内容时,服务器返回一个422不可处理的实体错误HTTP状态代码。在任一情况下,服务器应该包含一个包含OperationOutcome的响应正文,其中包含描述错误原因的详细错误消息。

    FHIR相关的错误返回的常见HTTP状态代码(除了与安全性,标头和内容类型协商问题相关的正常HTTP错误):

    · 400 Bad Request无法解析资源 或者基于FHIR的校验规则失败

    · 404 Not Found不支持此资源类别, or not a FHIR end-point

    · 422 Unprocessable Entity资源违反fhir说明或服务器业务规则。并返回一个operationoutcome资源提供额外的细节

    注意:服务器可以选择在接受创建时保留XML注释,说明和格式化或JSON空格,但不需要这样做。对数字签名的影响可能需要考虑。

    有关处理更新时系统可能表现的其他信息,请参阅提交的数据和检索的数据页面之间的变化。

    2.21.0.14.1 条件创建

    条件create交互允许客户端在服务器上尚不存在某些等效资源时创建新资源。客户端通过使用HL7定义的扩展头If-None-Exist提供FHIR搜索查询来定义在这种情况下的等价意思,如下所示:

    If-None-Exist: [search parameters]

    该参数只包含搜索参数(后面的URL)。

    当服务器处理此创建时,它将使用其资源类型的标准搜索工具执行搜索 。它采取的行动取决于找到了几个匹配:

    · No matches: 服务器如上所述处理创建

    · One Match:服务器忽略该帖子并返回200OK

    · Multiple matches: 服务器返回一个412前提条件失败错误,指出客户端的条件没有足够的选择

    此变体可用于避免两个客户端为同一记录创建重复资源的风险。例如,发布新实验室结果的客户端可能会指定,If-None-Exist:
    identifier=http://my-lab-system|123
    t以确保它不会创建重复的记录。

    请注意,事务和条件创建/更新/删除是复杂的交互,并不期望每个服务器都将实现它们。不支持条件创建的服务器应返回HTTP 412错误和OperationOutcome

    2.21.0.15 搜索

    这种交互基于一些过滤条件来搜索一组资源。交互可以通过几个不同的HTTP命令执行。

    GET [base]/[type]{?[parameters]{&_format=[mime-type]}}

    这将使用参数中表示的条件来搜索特定类型的所有资源。 由于某些用户代理和代理处理GETPOST请求的方式,除了上述基于获取的搜索方法之外,支持搜索的服务器还支持POST搜索:

    POST
    [base]/[type]/_search{?[parameters]{&_format=[mime-type]}}

    这与GET命令具有完全等效语义表达。所有这些搜索交互都需要一系列参数,这些参数是name=valueURL中编码的一系列对(或作为application/x-www-form-urlencoded提交POST)。(参见W3C
    HTML
    表单)。

    注意:application/x-www-form-urlencoded支持POST,以便通过浏览器中的HTML表单调用搜索GETPOST可以进行搜索(尽管浏览器可能需要相当大的活​​动内容),尽管这不是主要用途。

    按照搜索处理机制的规定处理搜索。

    如果搜索成功,服务器应返回一个200 OK HTTP状态代码,并且返回内容应该是一个Bundle 其中type = searchset 包含按照定义的顺序将搜索结果作为零个或多个资源的集合。结果集可能很长,因此服务器可能会使用分页。如果他们这样做,他们应该使用下面描述的方法 (根据RFC 5005Feed Paging and Archiving)进行修改),以将集合分成页面(如果适用),服务器也可以在包含附加信息的Bundle条目中返回一个OperationOutcome资源searchset;如果发送它不应该包含任何fatal或严重性的问题error ,并应标明一个 Bundle.entry.search.modeoutcome 如果搜索失败(不能执行,不是没有匹配),返回值是一个状态代码4xx5xxOperation

    FHIR相关的错误返回的常见HTTP状态代码(除了与安全性,标头和内容类型协商问题相关的正常HTTP错误):

    · 400 Bad Request无法处理或失败的基本FHIR验证规则

    · 401 Not Authorized所尝试的交互需要授权

    · 404 Not Found不支持资源类型,或不支持FHIR端点

    2.21.0.15.1 变化的搜索

    要搜索指定部分,请分别查看所有可能的资源或特定的资源类型:

    GET [base]/[Compartment]/[id]/{*?[parameters]{&_format=[mime-type]}}

    GET [base]/[Compartment]/[id]/[type]{?[parameters]{&_format=[mime-type]}}

    例如,检索与特定遇到相关联的特定LOINC代码的所有观察资源:

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

    请注意,有一些具体操作定义为支持获取整个病人记录 或遇到的所有记录。

    也可以搜索多种资源类型:

    GET [base]?_type=Condition,Observation&[parameters]{&_format=[mime-type]}

    这是在条件和观察中搜索的请求。在这种情况下,可以使用的唯一参数是为条件和观察(使用SearchParameter.base – 参见跨资源搜索参数)定义的参数或为所有资源定义的参数。如果没有列出SearchParameter.base任何参数的搜索列表类型,则这是一个错误,服务器应返回400状态。也可以一次搜索所有类型:

    GET [base]?[parameters]{&_format=[mime-type]}

    一次搜索所有资源时,只能为所有资源定义参数

    2.21.0.16 功能(能力)

    capabilities 互动检索服务器的能力语句定义它如何支持资源。交互由HTTP GET命令执行,如图所示:

    GET [base]/metadata {?_format=[mime-type]}

    OPTIONS command:

    另外还有另外一种使用HTTP OPTIONS 命令获取能力语句的方法:

    OPTIONS [base] {?_format=[mime-type]}

    但是,从STU3开始,此方法已被弃用,将在以后的版本中被删除。使用这样的OPTIONS不符合HTTP,并为跨原始资源共享支持创造了挑战。

    应用程序应返回一个能力声明,指定该GET命令支持哪些资源类型和交互。如果404从中返回未知GET,则指定的服务网址不支持FHIRETag应该通过CapabilityStatement返回一个标题。如果CapabilityStatement本身更改,则头部的值将更改。OPTIONSOMG hData
    RESTful Transport
    规范中定义了使用命令返回的附加参数。

    返回的Capability语句通常具有任意的id,并且没有元素,尽管它不被禁止。能力声明可能会变得相当大; 鼓励服务器来支持_summary _elements参数的功能作用,尽管这不是必需的。此外,鼓励服务器实现$subset $implements 操作,以便客户端检查一致性。

    除了这种capabilities相互作用,服务器也可以选择提供的标准集的相互作用s (read, search, create, update) 此页为上定义 CapabilityStatement
    Resource
    终点。这与capabilities互动不同:

    capabilities interaction

    返回描述服务器当前操作功能的能力声明

    CapabilityStatement end-point

    管理能力陈述库(如HL7能力声明注册表)

    所有服务器都需要支持capabilities交互,但服务器可以选择是否支持CapabilityStatement端点,就像任何其他端点一样。

    实现注意:在DSTU 2及更早版本中,此交互返回的资源被命名为“Conformance”。客户经常连接到服务器,并使用capabilities交互来检查它们是否与服务器版本和/或功能兼容。这样的客户端应该能够处理一致性或能力状态资源。

    2.21.0.17 批量/事务

    该交互batchtransaction交互在一次HTTP请求/响应中提交的服务器上执行的一系列操作。这些动作可以独立地作为批量执行,或作为单个原子事务执行,其中整个变更的数据集合作为单个实体整体全部成功或失败。在相同或不同类型的多个资源的多个动作可被一次性提交,他们支持此文档上定义的其他用户交互的操作(例如 read, search, create, update, delete,.), ,或使用操作(operations framework 框架。

    如果多个交互中其中某个交互失败将导致丧失资源的完整一致性,那么该transaction事务模式在需要多个交互的情况下就特别有用,(例如,当存储Provenance资源及其相应的目标资源时,或者在文档存储库中,文档索引条目可能会丢失引用完整性的风险)及其随附文件)。

    请注意,事务和条件创建/更新/删除是复杂的交互,并不期望每个服务器都将实现它们。

    A batchtransaction交互由HTTP POST命令执行,如图所示:

    POST [base] {?_format=[mime-type]}

    提交内容是一个Bundle 格式,指定的类型是: Bundle.type = batch or transaction.。每个条目都包含request详细信息(Bundle.entry.request),它提供了该操作的HTTP详细信息,以通知系统处理批处理或事务处理该条目的操作(注意:该选项request是可选的,但应该存在)。如果HTTP命令是PUTPOST,则该条目将包含该动作正文的资源。捆绑包中的资源分别进行处理,就像它们是本页面或操作框架中另有说明的单独交互或操作一样。这些操作受到每个操作的正常处理,包括元素,验证和版本感知更新以及事务完整性。

    例子:

    · Transaction
    Example
     with Matching Response

    · Batch request
    to fetch Meds & Allergies
     with Response

    · Batch request
    to fetch simple Patient Summary
     with Response

    2.21.0.17.1 批处理规则

    对于batch,更新Bundle中不同的条目之间不能有任何相互依赖关系,一个变化的成败不应该改变另一个成败或者产生另一个变化的内容。服务器应该验证。请注意,服务器以与下面规定的事务相同的顺序执行批处理,尽管执行顺序与前一条规则无关。 Bundle.entry.resource中的另一个 Bundle.entry.resource的静态引用被认为是不一致的。

    2.21.0.17.2 事务处理规则

    对于一个 transaction 事务,服务器应该接受所有的操作并返回一个200 OK,以及响应包(见下文),或者拒绝所有的资源并返回一个HTTP 400或者500类型的响应。如果提交的数据包中没有资源,它不是一个错误。处理事务的结果不是取决于事务中资源的顺序。资源只能在事务中出现一次(通过身份)。

    由于事务是原子的规则,其中所有操作都通过或失败,并且条目的顺序并不重要,因此处理操作有一个特定的顺序:

    1. 处理任何 DELETE 互动

    2. 处理任何 POST 互动

    3. 处理任何 PUT 互动

    4. 处理任何 GET 互动

    如果步骤1-3中出现资源身份重叠(包括从条件更新/删除),则事务将失败。

    STU 注意: 客户端能够请求作为事务的一部分执行操作。某些事务可能会导致副作用,例如创建新资源或可能难以适应事务框架的其他操作。在STU期间寻求有关此问题的意见。

    事务可以包括从包中的一个资源到另一资源的引用,包括资源相互指向的循环引用。如果服务器为捆绑包中的任何资源分配了新的id,则作为上述处理规则的一部分,它还会在处理相同的包中更新对该资源的任何引用。对不属于捆绑包的资源的引用保持不变。版本特定的引用在参考文献更新后应该保留为特定于版本的引用。服务器将取代在捆绑所有匹配的联系,无论他们是在资源ID,资源引用,URL元素中找到的,或<a href=”” & <img src=”” 在叙事。

    处理“POST”(创建)时,完整的URL将被视为资源上的ID,并被忽略; 服务器将生成一个新的资源ID。对于更新,服务器将在指定的fullUrl与服务器知道该本地实例URL之间执行映射(如果可能)。如果服务器没有fullUrl的映射,则服务器忽略基本URL,并尝试基于与服务器基础相同的更新。这允许将相同的事务包发送到多个系统,而不会更改每个目标的fullUrls

    当处理批处理或事务时,服务器可以选择尊重现有的逻辑ID(例如Observation/1234保留Observation/1234在服务器上),但是由于这仅在受控情况下是安全的,所以服务器可以选择为所有提交的资源分配新的id,而不管任何 id 在资源中声明逻辑,或 fullUrl 在批/事务中的条目。

    注意:此行为将根据实施经验进行验证,并可能会发生变化。条件参考

    当构建捆绑bundle包时,客户端可能不知道资源的逻辑ID,但是它可以知道识别信息例如身份标识符。当从v2消息构建事务时,这种情况常常出现。客户端可以使用搜索将该标识符解析为逻辑ID,但这意味着对于逻辑ID的解析不会在与提交相同的事务中发生(并且使客户端显着复杂化)。因此,在一个事务(而且只在一个事务中),对资源的引用可以被描述如何找到正确引用的搜索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″/>(注释:这里可能是 identifier value,也是是默认吧。)

    </subject>

    <–! rest of resource omitted –>

    </Observation>

    </resource>

    <request>

    <method value=”POST” />

    </request>

    </entry>

     <Bundle>

    搜索URI是相对于服务器的[base]路径,始终以资源类型开始: [type]:?parameters…。只允许过滤参数; 没有一个控制资源回报的参数是相关的。

    处理交易时,服务器应该:

    · 检查搜索URI的所有引用

    · 对于搜索URI,使用搜索来定位匹配的资源

    · 如果没有匹配或多个匹配,则事务失败,并向用户返回错误

    · 如果存在单一匹配,服务器将使用对匹配资源的引用来替换搜索URI

    2.21.0.17.3 批处理/事务响应

    用于批处理,或事务成功的情况下,服务器应返回一个捆绑类型 设置为 batch-response transaction-response 包含在请求中的每个条目的一个条目,以相同的顺序,以处理所述进入的结果。对于失败的事务,服务器返回单个OperationOutcome而不是Bundle 客户端可以使用返回的Bundle跟踪处理条目的结果以及服务器分配给资源的身份。每个条目元素应包含一个 response元素,其中详细说明了处理条目的结果 – HTTP状态代码以及 ETag 用于标识和版本化资源的位置和标题值。此外,资源可以包括在条目中,根据对Prefer 头指定。

    2.21.0.17.4 接受其他捆绑类型

    服务器可以选择接受批处理或事务以外的包类型,然后将它们发送到基础URL 类型的捆绑类型history固有地具有与一个相同的结构transaction,并且可以被视为事务或批处理,因此服务器应该接受历史包这使得可以使用pub(推送) / sub(发布)模型轻松地将数据从一个服务器复制到另一个服务器。但是请注意,原始事务边界可能不会在历史列表中表示,并且资源可能会在历史列表中发生多次,因此处理历史数据包的服务器必须具有一些管理策略。 对于其他Bundle类型,如果服务器选择接受它们,则不会有request元素(请注意,每个条目都将有一个资源)。在这种情况下,服务器将条目视为创建或更新交互,具体取决于它是否识别资源的身份如果资源的身份是指服务器上的有效位置,则应将其视为更新到该位置。注意:此选项允许客户端将匹配进程委派给服务器。

    2.21.0.18 历史

    历史交互检索特定资源,给定类型的所有资源或系统支持的所有资源的历史记录。历史交互的这三个变体通过HTTP GET命令执行,如图所示:

    GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}

    GET [base]/[type]/_history{?[parameters]&_format=[mime-type]}

    GET [base]/_history{?[parameters]&_format=[mime-type]}

    返回内容是一个Bundle 类型为history包含指定的版本历史记录,最后使用最旧版本排序,并包括已删除的资源。每个条目(entry)均最低限度包含任何一个持有交互结束就作为resource的资源,或带有entry.request.method request提供有关发生导致新版本的交互信息,并且允许,例如,需要区分创建和更新交互的订阅系统。资源可能丢失的主要原因是资源被其他的通道改变,而不是通过REST接口。如果entry.request.method PUT POST,则条目应包含资源。

    相互作用create, update, and delete 创建了历史条目。其他交互不会(请注意,这些操作可能会产生副作用,例如产生新的AuditEvent资源;这些可以认为是权限范围内的创建交互)。操作引起的新资源或者更新已存在的资源也会显示在历史记录中,同样,对REST接口范围之外的交互所产生的资源的更新也是如此。

    一个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>

    </entry>

    请注意,条件创建,更新和删除将转换为历史列表中的直接更新和删除。

    除了标准_format参数外,此交互的参数还可能包括:

    _count : integer

     

    返回请求的记录条数。服务器不一定会返回所请求的数目,也可能小于请求的数目。

    _since : instant

     

    只包括在给定时间内或之后创建的资源版本(也可能一个以上)

    _at : dateTime

    single

    只包括在日期时间值中指定的时间段(可能是一个以上)中当前某个时间点的资源版本

         

    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.

    通过指定_since包含具有时区的完整日期时间的参数,历史数据列表可能限制在有限的时间段内。客户应该知道,由于时间的不精确性,他们可能会多次接收边界资源更新的通知。服务器不需要支持比第二更精细的精度。

    更新列表可能很长,因此服务器可能会使用分页。如果他们这样做,他们应该使用下面描述的方法将列表分成页面(如果适用),并在页面之间维护指定的_count

    所述history相互作用可用于订阅设置从一个系统到另一个,从而使资源在它们之间同步。 有关系统同步的备用方法,请参阅订阅资源。

    关于维护资源历史的附加注意事项:

    · 历史是每个资源的记录版本历史。它不是要支持并发版本或多分支版本历史

    · 因此,无法更新或删除记录的过去版本,除了可以修改元数据(主要用于访问控制目的)

    · 资源的所有过去版本都被视为已被替换,并且不再活跃,但保留为审计/完整性目的

    · 在资源的过去版本需要明确记录为输入错误的情况下,请使用指向资源的过去版本的Provenance资源

    · 在跟踪特定资源的历史时,应用程序应检索与资源或其过去版本相关的任何来源资源

    · 如果对于不可用的历史记录(例如系统不保留类型的历史记录或特定实例),则服务器应返回404 Not Found以及解释问题的OperationOutcome

    2.21.0.19 交互完整性

    处理创建和更新交互时,FHIR服务器无需原样接受整个资源; 当随后通过读取交互来检索资源时,资源可能不同。差异可能有以下几个原因:

    · 服务器将更新的内容与现有内容合并

    · 服务器应用业务规则并更改内容

    · 服务器不完全支持资源的所有功能或可能的值 请注意,没有通用方法来合并现有内容或按照业务规则安全或可预测地更改内容可能的,安全的和/或需要的是高度依赖于上下文的。这些行为可能受到安全考虑的驱动。关于不完全的支持,客户端可以参考服务器的CapabilityStatement 配置文件引用来确定服务器不支持哪些功能或值。

    对于上述3个原因,服务器改变资源的程度,FHIR服务器将为其所属的生态系统创建实施后果,这将需要进行管理(即将花费更多)。因此,由于系统暴露FHIR资源的限制,服务器应尽可能少地更改资源。但是由于医疗保健中存在变异性,此规范允许服务器可能会在创建/更新时更改资源。

    类似地,在实现上下文制定关于合并内容或改变内容的特殊规则的程度上,该上下文将变得更昂贵维护。

    虽然这些规则关于服务器进行了说明,但类似的概念适用于客户端在与服务器交互的不同客户端系统不支持相同功能集的程度上,客户端和/或服务器将被迫实现自定义逻辑以防止信息丢失或损坏。

    其中一些问题可以通过遵循版本感知更新之上建立的模式来缓解。在这种模式中:

    · 服务器为read接受update 互动的任何资源提供交互

    · 在更新之前,客户端read是资源的最新版本

    · 客户端将其所需的更改应用于资源,保留其他信息(请注意扩展名相关规则)

    · 客户端将结果写回作为update交互,并且能够处理409 412响应(通常再次尝试)

    如果客户遵循这种模式,那么他们不了解的其他系统的信息将通过更新进行维护。

    请注意,服务器有可能选择维护将丢失的信息,但是服务器没有定义的方式来确定客户端是否省略了信息,因为它不支持(在这种情况下),或者是否它希望删除信息。

    2.21.0.19.1 一致性

    客户端和服务器系统都应该清楚地记录如何处理事务完整性。

    STU Note: 现在,记录如何处理事务完整性的唯一方法是作为CapabilityStatement 资源的叙述部分中的文本。欢迎使用此信息的试用期内的反馈意见(如果有的话)

    2.21.0.20 分页

    如果服务器为搜索或历史(search or history)交互的结果提供分页,则它们应符合此方法(根据RFC 5005 (Feed
    Paging and Archiving
    )
    进行修改),用于在返回Bundle (例如,使用 history and search)时发送连续链接到客户端,如果服务器不这样做,那么没有办法继续分页。

    此示例显示搜索结果的第三页:

    <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>

    服务器不需要使用本示例所示的有状态的分页方法服务器可以决定如何最好地确保继续在资源持续更改的上下文中保持完整性。一种替代方法是对边界上的记录使用特定于版本的引用,但是当更新记录时,这将会导致连续性故障。

    服务器可以向链路添加附加的状态跟踪参数,如上例所示。客户端必须使用服务器提供的链接才能遍历页面。服务器可以通过使用Bundle.total. 通知客户端分页结果的交互返回的资源总数。

    请注意,对于搜索,哪里 _include 可以用于返回额外的相关资源,Feed中的资源总数可能会超过totalResults中指示的数字。

    2.21.0.21 中介

    HTTP协议可以通过HTTP代理路由。这些代理对应用程序是透明的,尽管实现者应该警惕缓存的影响,特别是包括接收不合格内容的风险。有关 详细信息, 请参阅HTTP规范

    接口引擎也可以放置在消费者和提供者之间。这些不同于代理,因为它们主动地更改HTTP交换的内容和/或目的地,并且不受适用于HTTP代理的规则的限制。允许这样的代理,但是应该标记HTTP头来协助进行故障排除。

    任何修改HTTP请求或HTTP代理规则以外的HTTP请求或响应内容的代理都可以向HTTP头添加一个标记,如下所示:

    request-modified-[identity]: [purpose]

    response-modified-[identity]: [purpose]

    请求修改 – [身份][目的] 响应修改 – [身份][目的] 身份应该是由代理管理员定义的单一令牌,可以在使用上下文中充分识别代理。标题应指定代理修改内容的目的。端点系统不得将此头用于任何目的。其目的是协助系统故障排除。

    2.21.0.22 OMG hData
    RESTful
    传输

    这里描述的RESTful规范是基于OMG Health RESTful规范(HData)。在这方面,FHIR作为该规范中描述的记录格式简档。请注意以下重要因素:

    · FHIRhData部分映射到资源类型,将hData文档映射到资源实例。没有子部分,客户端系统不能创建新的部分,尽管分区行为有些像部分

    · 因为客户端不能提交新的部分 (POST 服务URL), POST 服务URL已被重新用于事务交互(差异在审查中)

    · FHIR还没有定义根文档。定义时,它将包含有关FHIR服务器已完成的信息(与能力声明相反,该功能描述了它能够做什么)

    · 请注意,此规范确实支持 OPTIONS 服务URL上的hData RESTful Transport 命令

    2.21.0.23 总结

    这些表格介绍了这里描述的相互作用。请注意,所有请求可能包括一个可选的Accept标题来指示用于响应的格式(DELETE由于可以返回一个OperationOutcome ,所以这样也是如此)。

    Interaction

    Path

    Request

     

    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/[vid]

    GET

    N/A

    N/A

    N/A

    N/A

    update

    /[type]/[id]

    PUT

    R

    Resource

    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

    Parameters

    N/A

    N/A

    GET

    N/A

    N/A

    N/A

    N/A

    POST

    application/x-www-form-urlencoded

    form data

    N/A

    N/A

    · N / A =不存在,R =必需,O =可选

    · 对于所有资源(包括对元素的直接访问)定义的操作,请参阅Resource Operations

    Interaction

    Response

     

    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)

    R on create

    R: ETag, Last-Modified

    200, 201, 400, 404, 405, 409, 412, 422

     

    delete

    R if body

    O: OperationOutcome

    N/A

    N/A

    200, 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: CapabilityStatement

    N/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/Resource

    N/A

    N/A

    200

     

    注意:此表列出了此处描述的状态代码,但其他状态代码可能按照HTTP规范所述。附加代码可能是服务器错误和与认证协议相关联的各种代码。

    • 该话题由  wyp 于 1 年, 5 月 前 修正。
    • 该话题由  admin 于 1 年, 2 月 前 修正。
    • 该话题由  admin 于 1 年, 2 月 前 修正。
正在查看 1 帖子:1-1 (共 1 个帖子)

抱歉,回复话题必需登录。