在开启版本管理的情况下，FHIR资源的删除操作与平常认知有些不同，在这里说明一下。

版本管理设计

在聊删除操作之前，先看看下面资源版本管理设计的逻辑概念图。

当一个资源存在多个版本时，最新的记录存储在当前记录区，所有的CRUD操作都是针对这个存储区进行的。而这个资源的所有历史记录都存储在历史记录区。必须说明一点的是，在这两个存储区存储的记录并不是资源本身，而是资源的索引数据（或者叫元数据）。而真正的资源是存储在资源存储区的，资源记录中有个指针指向该资源在资源存储区的位置。

与版本管理相关的字段有4个：

1. logical id: 资源在当前服务器上的唯一标识号
2. version: 资源的版本号，递增
3. last updated: 资源的最后更新时间
4. status: 资源的删除标记位(true|false)，标识着该资源是否被删除

其中，前3个字段在资源中也是可以找到的，存在着对应关系。但是字段删除标记位(status)在资源中是不存在的，只存在于资源的记录（索引数据、元数据）中。

<Patient xmlns="http://hl7.org/fhir">
  <id value=“609"/> 
  <meta> 
    <versionId value="v1"/> 
    <lastUpdated value="2020-11-23T12:34:45"/> 
  </meta> 

</Patient>

以上是一种逻辑模型设计，在实现时根据实际情况由厂商自行决定如何实现。

删除操作

现在，有个资源已经存在两个版本了，存储空间布局如下：

现在，删除该资源：

DELETE https://[baseurl]/[resource]/[id]

资源删除后的存储空间布局如下：

我们可以看到，资源的删除操作也是新增一条信息记录，版本号会递增。这一点与通常的认知是不一样的。同时，记录的删除标记字段被设置为true。这也表明，即使是被删除的记录也是存在于当前存储区的。

我们也看到，资源的删除记录是没有指向资源的，或者说，指向了空(NULL)。

FHIR规范中要求：

当读取一个本就不存在的资源时，应返回状态码404 Not Found；而读取一个被删除的资源时，应返回状态码410 Gone。

这种设计还可以用来区分一个资源是”本来就不存在“，还是”原来存在，现在不存在了“。

最后需要强调的是，删除了的资源也是可以恢复的，通过调用资源的update方法：

PUT https://[baseurl]/[resource]/[id]

把资源的新内容重新和该资源标识(id)关联在一起。资源的新内容可以和删除前一样，也可以不一样。

资源恢复后的存储空间布局如下：

又是一个与常识不一致的情况，恢复后的资源版本继续递增，而不是回到上一个版本号。

从这个设计理念上，我们可以总结出：资源的所有编辑性操作记录永远是新增的，不会去修改已有记录。而且，版本号是递增的，不会回退。