从其他项目中拷贝项目结构,先完成第一步的提交

This commit is contained in:
YuCheng Hu 2024-04-08 18:16:06 -04:00
parent a1018a1652
commit c0f1edf4e9
20 changed files with 1164 additions and 0 deletions

10
.idea/.gitignore vendored Normal file
View File

@ -0,0 +1,10 @@
# Default ignored files
/shelf/
/workspace.xml
# Editor-based HTTP Client requests
/httpRequests/
# Datasource local storage ignored files
/dataSources/
/dataSources.local.xml
# Zeppelin ignored files
/ZeppelinRemoteNotebooks/

16
.idea/checkstyle-idea.xml Normal file
View File

@ -0,0 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="CheckStyle-IDEA" serialisationVersion="2">
<checkstyleVersion>10.14.2</checkstyleVersion>
<scanScope>JavaOnly</scanScope>
<copyLibs>true</copyLibs>
<option name="thirdPartyClasspath" />
<option name="activeLocationIds" />
<option name="locations">
<list>
<ConfigurationLocation id="bundled-sun-checks" type="BUNDLED" scope="All" description="Sun Checks">(bundled)</ConfigurationLocation>
<ConfigurationLocation id="bundled-google-checks" type="BUNDLED" scope="All" description="Google Checks">(bundled)</ConfigurationLocation>
</list>
</option>
</component>
</project>

6
.idea/vcs.xml Normal file
View File

@ -0,0 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="VcsDirectoryMappings">
<mapping directory="" vcs="Git" />
</component>
</project>

39
CONTACT.md Normal file
View File

@ -0,0 +1,39 @@
# 联系方式
请使用下面的联系方式和我们联系:
| 联系方式名称 | 联系方式 |
|--------|-----------------------------------------------|
| 电子邮件 | [service@ossez.com](mailto:service@ossez.com) |
| QQ 或微信 | 103899765 |
| 社区论坛 | https://www.isharkfly.com/ |
# 公众平台
我们建议您通过社区论坛来和我们进行沟通,请关注我们公众平台上的账号。
## 微信公众号
![](https://cdn.ossez.com/img/cwikius/cwikius-qr-wechat-search-w400.png )
## 头条号
![](https://cdn.ossez.com/img/cwikius/cwikus-qr-toutiao.png)
## 百家号
![](https://cdn.ossez.com/img/sharkfly/baidu/baidu-qr.jpg)
## 知乎
https://www.zhihu.com/people/huyuchengus
## 快速导航
在下面的表格中,我们列出了有用的 iSharkFly 相关软件开发使用教程的导航,欢迎访问下面的链接获得更多的内容和参与讨论:
| 网站名称 | URL | NOTE |
|--------------------|----------------------------------------------------------------|---------------------------|
| WIKI 维基 | [track.ossez.com](https://track.ossez.com/articles) | YouTrack 部署的 WIKI 知识库 |
| DOCS.ISHARKFLY.COM | [https://docs.isharkfly.com/#/](https://docs.isharkfly.com/#/) | 本手册的编译版本将会部署在这个链接上 |
| CN 博客 | [http://www.cwikius.cn/](http://www.cwikius.cn/) | CWIKIUS.CN 一个有独立思考和温度的清新站 |

20
LINKS.md Normal file
View File

@ -0,0 +1,20 @@
# Links
In this page, we provide the quick reference link can help you increase ability to learning and coding.
## JDK
| Webiste | Links |
|---------|-----------------------------------------------------|
| Oracle | https://www.oracle.com/java/technologies/downloads/ |
| OpenJDK | https://adoptium.net/temurin/releases/ |
## Useful Links
| Webiste | Links |
|----------------|-------------------------------------------------|
| Eclipse | https://www.eclipse.org/ |
| GitHub | https://github.com/ |
| stackoverflow | https://stackoverflow.com/questions/tagged/java |
| Apache Commons | https://commons.apache.org/ |

11
_sidebar.md Normal file
View File

@ -0,0 +1,11 @@
- HIS 医疗数据信息化
- [Readme](README.md)
- [Contact](CONTACT.md)
- [FHIR In Action](fhir-in-action/index.md)
- [Week 2](week-2/index.md)
- [Week 3](week-3/index.md)
- [Week 4](week-4/_index.md)
- Week 5
- Week 6
- Week 7
- [Links](LINKS.md)

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

View File

@ -0,0 +1,9 @@
- [FHIR 简介](/fhir-in-action/introduction/index.md)
- [开发者眼中的 FHIR](/fhir-in-action/introduction/toreader.md)
- [FHIR 实现](/fhir-in-action/introduction/fhir-mplementation.md)
- [FHIR 概述](/fhir-in-action/introduction/fhir-overview.md)
- [FHIR 开发者指南](/fhir-in-action/introduction/fhir-dev-guide.md)
- [开放数据](/fhir-in-action/introduction/open-data-is-coming.md)
- [Install JDK](/fhir-in-action/install_jdk.md)
- [Install Eclipse](/fhir-in-action/introduction/install_eclipse.md)
- [Naming Conventions](/fhir-in-action/naming_conventions.md)

37
fhir-in-action/index.md Normal file
View File

@ -0,0 +1,37 @@
# FHIR In Action
---
针对 FHIR 标准的指南和示例以及相关内容的讨论。
FHIR® Fast Health Interoperable Resources (Index - FHIR v5.0.0) 是由 HL7 提出的新一代标准框架。
FHIR 整合了 HL7 V2,V3 和 CDA 的优点,同时利用了最新的Web标准,紧紧围绕着 implementability 开发和实现。
如还想了解更多有关 FHIR 的定义请访问链接https://www.isharkfly.com/t/hl7-fhir/15160
## 版权
本文本遵守开源著作权的开放版权协议,你可以:
* 下载、保存以及打印本书
* 网络链接、转载本书的部分或者全部内容,但是必须在明显处向读者提供访问本书发布网站的链接
* 在你的程序中任意使用本书所附的程序代码,但是由本书的程序所引起的任何问题,作者不承担任何责任
## 在线电子版本
在线电子版本请访问https://fhir.isharkfly.com
## 参考和框架
| 网站名称 | URL | NOTE |
|-----------------|-----------------------------------------------------------------------------|-------------|
| iSharkFly | https://www.isharkfly.com/c/industry-software/hospital-information-system/6 | HIS 相关信息 |
| David Hay 博客 | http://fhirblog.com/ | |
| Ewout Kramer 博客 | https://fire.ly/ | |
| 硕士论文 | https://github.com/JaneBlue/PPTpaper | |
| FHIR GitHub 参考 | https://github.com/wanghaisheng/fhir-in-action/ | |
| HAPI FHIR 库源代码 | https://github.com/hapifhir/hapi-fhir | |
| SMART 技术文档 | https://github.com/smart-on-fhir/smart-on-fhir.github.io | |
| Fhirbase | https://github.com/fhirbase | 使用 Go 和技术方案 |

View File

@ -0,0 +1,411 @@
## 1.7.1 开发者指南
FHIR (Fast Health Interoperability Resources)旨在数据交换能够支撑医疗领域的多种流程。该标准基于Restful的最佳实践能够实现跨团队的医疗系统的集成。
FHIR 所支持的范围很广泛,包括人、兽医、临床、公共卫生、临床试验、管理和财务等方面。全球通用且支持多种架构和场景。
### 1.7.1.1 框架
FHIR 是基于 `资源`这一通用组件. 每个资源都有如下 [通用特征](resources.html):
* 用URL来标识
* 通用的元数据
* [供人可读的XHTML概述](narrative.html)
* 通用的数据元集合
* [扩展的框架](extensibility.html)以支持医疗中的多样性
资源要么是 [XML](xml.html) ,要么是 [JSON](json.html)格式的. 目前已经定义了99种[资源类型](resourcelist.html)
### 1.7.1.2 Patient实例
如何用JSON来表示[patient](patient.html)。 标准中也定义了XML的表达方式。
```
{
"resourceType": "Patient",
"id" : "23434",
"meta" : {
"versionId" : "12",
"lastUpdated" : "2014-08-18T01:43:30Z"
}
"text": {
"status": "generated",
"div": "<!-- Snipped for Brevity -->"
},
"extension": [
{
"url": "http://example.org/consent#trials",
"valueCode": "renal"
}
],
"identifier": [
{
"use": "usual",
"label": "MRN",
"system": "http://www.goodhealth.org/identifiers/mrn",
"value": "123456"
}
],
"name": [
{
"family": [
"Levin"
],
"given": [
"Henry"
],
"suffix": [
"The 7th"
]
}
],
"gender": {
"text": "Male"
},
"birthDate": "1932-09-24",
"active": true
}
````
每个资源包括如下内容:
* **resourceType** (line 2) - 必须要有: FHIR 中定义了多种资源类型,详细列表请查看[the full index](resourcelist.html)
* **id** (line 3) - 资源自身的id(而非资源中数据的ID 相当于资源在数据库中的主键). 一般而言都是要有的,除了在新建时之外。
* **meta** (lines 4 - 7) - 通常要由 : [所有资源都会有的属性(这里和其他地方对元数据的定义略有偏差参考https://github.com/memect/hao/issues/296)](resources.html#meta)受基础架构控制. 如果没有元数据可以为空
* **text** (lines 12 - 17) - 推荐使用: XHTML 包含了资源中 [供人可读的部分](narrative.html)
* **extension** (lines 12 - 17) - 可选: [Extensions](extensibility.html)由扩展框架所定义
* **data** (lines 18 - 43) - 可选: 每种资源所定义的数据项。
备注 尽管标准中总是以所定义的顺序来显示JSON中数据的顺序但很多JSON库有其他排序标准。
### 1.7.1.3 交互
为了操作数据FHIR 定义了[REST API](http.html):
* [Create](http.html#create) = POST https://example.com/path/{resourceType}
* [Read](http.html#read) = GET https://example.com/path/{resourceType}/{id}
* [Update](http.html#update) = PUT https://example.com/path/{resourceType}/{id}
* [Delete](http.html#delete) = DELETE https://example.com/path/{resourceType}/{id}
* [Search](http.html#search) = GET https://example.com/path/{resourceType}?search parameters...
* [History](http.html#history) = GET https://example.com/path/{resourceType}/{id}/_history
* [Transaction](http.html#transaction) = POST https://example.com/path/
* [Operation](operations.html) = GET https://example.com/path/{resourceType}/{id}/${opname}
除了RESTful API之外,FHIR 中还定义了其他的数据交换方式,包括 [文档](documents.html),
[消息](messaging.html)和其他类型的[服务](services.html).
### 1.7.1.4 对多样性的管理
医疗行业的一大特点就是不同地区和细分行业都存在很大的差异性,并不存在一个集中式的权威机构来定义通用的行业规范。鉴于此,
FHIR 中定义了[通用扩展框架](extensibility.html)和
[管理多样性的框架](profiling.html).
### 1.7.1.5 新增资源
为了[新增资源](http.html#create), 需要发送一个 HTTP 的 POST 请求到某个资源节点(也就是某个URL).如下所示
```
POST https://example.com/path/{resourceType}
````
```
POST {some base path}/Patient HTTP/1.1
Authorization: Bearer 37CC0B0E-C15B-4578-9AC1-D83DCED2B2F9
Accept: application/json+fhir
Content-Type: application/json+fhir
Content-Length: 1198
{
"resourceType": "Patient",
...
}
````
向服务器提交一条患者记录, 服务器可以根据自己的情况分配ID来存储该患者记录。备注
* **/Patient** (line 1) - 处理所有患者的节点- 这里使用资源类型的名称
* **Authorization** (line 2) - 参考 [Security for FHIR](security.html)
* **Accept, Content-Type** (lines 3-4) - 如果资源的数据是JSON格式content type需要设置成这样application/json+fhir (XML的话设置成 application/xml+fhir). 数据的编码始终是UTF-8
* **id** (line 9) - 待新建的记录中并没有id由服务器来分配
* Resource Content, lines 8+ - 这时候也没有任何元数据。资源的其他部分同上述示例
### 1.7.1.6 新增资源的响应
响应中包含HTTP 201表示服务器已经成功新建该条记录。location header 属性中包含了访问该资源的URL。响应中亦可包含[OperationOutcome](operationoutcome.html) 资源来表达处理的一些细节,并不做硬性要求。
```
HTTP/1.1 201 Created
Content-Length: 161
Content-Type: application/json+fhir
Date: Mon, 18 Aug 2014 01:43:30 GMT
ETag: "1"
Location: http://example.com/Patient/347
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">The operation was successful</div>"
}
}
````
Notes:
* **HTTP/1.1 201** (line 1) - 操作成功. Note that HTTP/1.1 is strongly recommended but not required
* **ETag** (line 5) - used in the [version aware update](http.html#update) pattern
* **Location** (line 6) - the id the server assigned to the resource. The id in the url must match the id in the resource when it is subsequently returned
* **operationOutcome** (line 9) - OperationOutcome resources in this context have no id or meta element (they have no managed identity)
#### 1.7.1.6.1 Error response
出于多种原因服务器会返回一个错误信息FHIR 内容相关的一些错误信息以HTTP 状态码加一个[OperationOutcome](operationoutcome.html)来表达.
如下是一个不满足服务器端业务规则时的返回信息:
```
HTTP/1.1 422 Unprocessable Entity
Content-Length: 161
Content-Type: application/json+fhir
Date: Mon, 18 Aug 2014 01:43:30 GMT
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">MRN conflict
- the MRN 123456 is already assigned to a different patient</div>"
},
}
````
Notes:
* 服务器可通过[OperationOutcome](operationoutcome.html)来表达更为详细的错误信息
### 1.7.1.7 Read Request
[读取资源内容](http.html#read)是通过HTTP GET请求来实现的.
```
GET https://example.com/path/{resourceType}/{id}
````
```
GET /Patient/347?_format=xml HTTP/1.1
Host: example.com
Accept: application/xml+fhir
Cache-Control: no-cache
````
Notes:
* **347** (line 1) - 要访问资源的id
* **_format=xml** (line 1) - 希望返回的数据格式这种方式适合于客户端无法访问HTTP 头信息的情况例如XSLT转换时也可以通过HTTP 头中的accept字段来指定(see [Mime Types](http.html#mimetypes)
* **cache control** (line 4) - 如何控制并发是很重要的但FHIR中并未做出规定,更多信息请参考[http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html) 或者 [https://www.mnot.net/cache_docs/](https://www.mnot.net/cache_docs/)
### 1.7.1.8 Read Response
读取单个资源内容GET请求的响应是单独的一个资源.
```
HTTP/1.1 200 OK
Content-Length: 729
Content-Type: application/xml+fhir
Last-Modified: Sun, 17 Aug 2014 15:43:30 GMT
ETag: "1"
<?xml version="1.0" encoding="UTF-8"?>
<Patient xmlns="http://hl7.org/fhir">
<id value="347"/>
<meta>
<versionId value="1"/>
<lastUpdated value="2014-08-18T01:43:30Z"/>
</meta>
<!-- content as shown above for patient -->
</Patient>
````
Notes:
* **id** (line 8) - 资源的id与请求中的id一致
* **versionId** (line 11) - 该资源的最新版本. 最佳实践中要求该值与 ETag值匹配 (see [version aware update](http.html#update)), 对于客户端而言,不能认为二者总是匹配的. 一部分服务器并不记录资源的版本信息。
* 尽管建议服务器能够保留版本信息,但不做强制性要求
* **lastUpdated** (line 12) - 如果存在该字段字段值应与HTTP header中的值保持一致
### 1.7.1.9 Search Request
除了读取单个资源内容之外,也可以通过[查询参数和变量](search.html) [查询资源内容](http.html#search),形式一般如下:
<div class="example">
<pre class="http">
GET https://example.com/path/{resourceType}?criteria
</pre>
</div>
The criteria is a set of
http parameters that specify which resources to return. The search operation
<div class="example">
<pre class="http">
https://example.com/base/MedicationPrescription?patient=347
</pre>
</div>
会返回该患者的所有处方信息.
### 1.7.1.10 Search Response
查询请求返回的对象是一个[bundle](extras.html#bundle): 如未明确要求,只返回满足查询参数要求的资源元数据:
```
{
"resourceType": "Bundle",
"id" : "eceb4882-5c7e-4ca4-af62-995dfb8cef01"
"meta" : {
"lastUpdated" : "2014-08-19T15:43:30Z"
},
"base": "http://example.com/base",
"total": "3",
"link": [
{
"relation" : "next",
"url" : "https://example.com/base/MedicationPrescription?patient=347&searchId=ff15fd40-ff71-4b48-b366-09c706bed9d0&page=2"
}, {
"relation" : "self",
"url" : "https://example.com/base/MedicationPrescription?patient=347"
}
],
"entry": [
{
"resource" : {
"resourceType": "MedicationPrescription",
"id" : "3123",
"meta" : {
"versionId" : "1",
"lastUpdated" : "2014-08-16T05:31:17Z"
},
... content of resource ...
},
},
... 2 additional resources ....
]
}
````
Notes:
* **resourceType** (line 7) - &quot;SearchResults&quot; is the name for a bundle returned from a search
* **id** (line 3) -服务器为该次查询响应bundle的唯一标识. 有些情况下要求该id满足 [ 全球唯一](extras.html#bundle-unique)
* **meta.lastUpdated** (line 10) - This should match the HTTP header, and should be the date the search was executed, or more recent, depending on how the [server handles ongoing updates](search.html#currency). The lastUpdated data SHALL be the same or more recent than the most recent resource in the results
* **base** (line 12) - 返回的内容中所有[资源引用](references.html) 相对地址的根地址。
* **total** (line 13) - 满足查询条件的记录数量. 这里的数量指的是总数而非仅该bundle中所包含的数量详情查看 [可以对结果进行分页查询](http.html#search)
* **link** (line 14) - A set of named links that give related contexts to this bundle. Names defined in this specification: [first](http.html#search), [prev](http.html#search), [next](http.html#search), [last](http.html#search), [self](http.html#search)
* **item** (line 23) - 用来表达满足查询条件的实际资源的元数据信息
* 如果加上include标签可以强制要求服务器在返回结果中包含资源的内容详情请参阅[return additional related resources](search.html#include)
### 1.7.1.11 Update Request
客户端用新版本的资源记录替换服务器中的老版本.
```
PUT https://example.com/path/{resourceType}/{id}
````
Note that there does not need to be a resource already existing at {id} - the server may elect to automatically create the resource at the specified address. Here is an example of updating a patient:
```
PUT /Patient/347 HTTP/1.1
Host: example.com
Content-Type: application/json+fhir
Content-Length: 1435
Accept: application/json+fhir
If-Match: 1
{
"resourceType": "Patient",
"id" : "347",
"meta" : {
"versionId" : "1",
"lastUpdated" : "2014-08-18T01:43:30Z"
},
...
}
````
Notes:
* **resourceType** (line 1) - &quot;Patient&quot; URL请求中的资源类型必须与提交的数据中的资源类型保持一致 (line 9)
* **resource id** (line 1, &quot;347&quot;) - URL中的资源id必须与提交的数据中id值保持一致(line 9)
* **If-Match** (line 6) - 如果存在该字段必须与资源内容中的meta.versionId值保持一致 (line 12), 服务器必须核实版本的完整性如果不支持版本则返回412状态码
* **meta.lastUpdated** (line 10) - This value is ignored, and will be updated by the server
* **resource content** (line 14) - 这里省略了资源内容
### 1.7.1.12 Update Response
更新请求的响应包括了元数据、状态和OperationOutcome(可选):
```
HTTP/1.1 200 OK
Content-Length: 161
Content-Type: application/json+fhir
Date: Mon, 18 Aug 2014 01:43:30 GMT
ETag: "2"
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">The operation was successful</div>"
}
}
````
Notes:
* **ETag** (line 5) - This is the versionId of the new version
### 1.7.1.13 Base Resource Content
所有资源都会包含的基础信息:
```
{
"resourceType" : "X",
"id" : "12",
"meta" : {
"versionId" : "12",
"lastUpdated" : "2014-08-18T01:43:30Z",
"profile" : ["http://example-consortium.org/fhir/profile/patient"],
"security" : [{
"system" : "http://hl7.org/fhir/v3/ActCode",
"code" : "EMP"
}],
"tag" : [{
"system" : "http://example.com/codes/workflow",
"code" : "needs-review"
}]
},
"implicitRules" : "http://example-consortium.org/fhir/ehr-plugins",
"language" : "X"
}
````
Implementers notes:
* **resourceType** (line 2) - 每个资源都会资源类型的字段. XML的话也就是根节点
* **id** (line 3) - 在资源新建之时分配后不再变化.只有在初次创建该资源时才没有该字段
* **meta.versionId** (line 5) - 当资源内容(除了meta.security、meta.profile、meta.tag三个之外)发生变更时该值随之变化
* **meta.lastUpdated** (line 6) - 随versionId的变化而变化. 如果服务器不维护版本信息,则不用记录该字段
* **meta.profile** (line 7) - 表示资源的内容是否遵循某个规范(比方说满足阿里健康的开放API的要求或者说满足卫计委共享文档中的要求). 更多信息请参考 [Extending and Restricting Resources](profiling.html#resources). 当规范、值集本身发生变动时可以更改该字段的值
* **meta.security** (lines 8 - 11) - [安全类标签](securitylabels.html). 该标签将资源与某些安全策略、基础架构策略联系起来。该字段的值可随资源内容的变动而变动,或者随安全体系的控制。
* **meta.tag** (lines 12 - 16) - [其他类型的标签](extras.html). 如需将资源与特定的工作流程关联起来可以使用此类标签.在解读资源内容时无需考虑此类标签的值 。对此类标签值的更新不会影响资源内容版本的变化 [updated](http.html#tags) (这里好像是说 可以不变更资源的版本就修改tag标签的值 还是说tag值的修改压根就不影响资源版本 其他的security和profile tag三个字段是否都适用呢待考证)
* **implicitRules** (lines 17) - 如何准确安全的处理资源内容而在发送接收双方达成的[协议](profiling.html#agreement). 由于使用了该字段就意味着其他系统要使用其中的数据可能会出现解读错误的情况,限制了数据的重复利用,故不推荐适用该字段
* **language** (lines 18) - [资源内容所采用的表达语言](narrative.html#language). 当前,资源内容中亦可包含其他语言的内容; 该字段表示的是资源的主要语言。
&copy; © HL7.org 2011+. FHIR DSTU (v0.5.0-5149) generated on Fri, Apr 3, 2015 14:36+1100\.
链接:[试行版是什么](http://hl7.org/implement/standards/fhir/dstu.html) |[版本更新情况](http://hl7.org/implement/standards/fhir/history.html) | [许可协议](http://hl7.org/implement/standards/fhir/license.html) |[提交变更建议](http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemAdd&tracker_id=677)

View File

@ -0,0 +1,104 @@
## FHIR Implementation
* The current specification: [http://www.HL7.org/fhir/](http://www.HL7.org/fhir/) (or [the development version](http://hl7.org/implement/standards/FHIR-Develop/))
* [FHIR Profiles from other Organizations](/index.php?title=FHIR_Profiles_from_other_Organizations "FHIR Profiles from other Organizations")
* Contact Information
* Implementation help: [[ask questions about FHIR](http://stackoverflow.com/questions/tagged/hl7_fhir)]
* Formal Contact point for the project: [[fmgcontact@hl7.org](mailto:fmgcontact@hl7.org)]
* [Skype Group Chats](/index.php?title=FHIR_Skype_Chat "FHIR Skype Chat")
* [FHIR gForge Tracker](http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677) for change requests/corrections
* FHIR Project Team Leads (FHIR Core Team): [[Grahame Grieve](mailto:grahame@healthintersections.com.au)], [[Ewout Kramer](mailto:e.kramer@furore.com)], [[Lloyd Mckenzie](mailto:lloyd@lmckenzie.com)]
* [List server](/index.php?title=FHIR_email_list_subscription_instructions "FHIR email list subscription instructions") - project email list
* Help / Getting Started
* [FHIR Starter](/index.php?title=FHIR_Starter "FHIR Starter") - tutorial for FHIR newbies
* [FHIR Cheat Sheet](http://www.furore.com/wp-content/uploads/2014/11/FURORE-CHEATSHEET-FHIR-R3.pdf) (DSTU 1)
* [Help desk FAQs & knowledge-base articles](https://healthlevelseven.desk.com/) (HL7 members only)
* [FHIR Tools Registry](/index.php?title=FHIR_Tools_Registry "FHIR Tools Registry") - a list of useful tools for FHIR implementers
* [FHIR for Clinical Users](/index.php?title=FHIR_for_Clinical_Users "FHIR for Clinical Users") - an introduction to FHIR for non-technical people that will migrate to the specification in the future
* [FHIR User Group](/index.php?title=FHIR_User_Group "FHIR User Group")
* Social Media on FHIR
* FHIR blogs [David Hay](http://fhirblog.com/), [Ewout Kramer](http://thefhirplace.com/), [Grahame Grieve](http://www.healthintersections.com.au/)
* FHIR News on Twitter [FHIR News](http://www.twitter.com/FHIRnews)
* FHIR Videos [HIMSS FHIR Session](https://live.blueskybroadcast.com/bsb/client/CL_DEFAULT.asp?Client=556675&PCAT=8341&CAT=8341&Review=true), [HL7.tv](http://www.hl7.tv/FHIR.html) and [Ringholm](https://vimeo.com/channels/hl7fhir).
* Testing
* [Publicly Available FHIR Servers for testing](/index.php?title=Publicly_Available_FHIR_Servers_for_testing "Publicly Available FHIR Servers for testing")
* [Open Source FHIR implementations](/index.php?title=Open_Source_FHIR_implementations "Open Source FHIR implementations")
* [FHIR Connectathon 8](/index.php?title=FHIR_Connectathon_8 "FHIR Connectathon 8") (January, San Antonio)
* [Organizations interested in FHIR](/index.php?title=Organizations_interested_in_FHIR "Organizations interested in FHIR")
* [Profile Tooling](/index.php?title=Profile_Tooling "Profile Tooling")
* [FHIR Implementations](/index.php?title=FHIR_Implementations "FHIR Implementations")
* Connectathons
* [Connectathon 9](http://wiki.hl7.org/index.php?title=FHIR_Connectathon_9) (May 9-10, Paris, France)
* Previous Connectathons and other events
* [Historical Connectathons](/index.php?title=Category:FHIR_Connectathons "Category:FHIR Connectathons") (list)
* [Clinical Connectathon 1](/index.php?title=FHIR_Clinical_Connectathon_Initiative "FHIR Clinical Connectathon Initiative") (September 2014, Chicago) (+ [Clinical Connectatathon 1 Tooling](/index.php?title=Clinical_Connectatathon_1_Tooling "Clinical Connectatathon 1 Tooling"))
* [2 day seminar and Connectathon](http://www.healthintersections.com.au/?p=2237) (Nov 6-7, Melbourne Australia)
* [International FHIR Development Days](http://fhir.furore.com/devdays/) (Nov 24-26, Amsterdam)
## FHIR Development
* How to
* [FHIR DSTU monitoring](/index.php?title=FHIR_DSTU_monitoring "FHIR DSTU monitoring") - how to monitor DSTU feedback
* [FHIR Ballot Prep](/index.php?title=FHIR_Ballot_Prep "FHIR Ballot Prep") - tasks for the next ballot and milestone dates
* [FHIR Build Process](/index.php?title=FHIR_Build_Process "FHIR Build Process") - Setting up and running the FHIR build process
* [Technical Guide](/index.php?title=FHIR_Guide_to_Authoring_Resources "FHIR Guide to Authoring Resources") - How to create resources
* Materials: [gForge](http://gforge.hl7.org/gf/project/fhir/), [SVN Trunk](http://gforge.hl7.org/svn/fhir/trunk)
* For read-only SVN access, use "anonymous" and your email as a password.
* For Commit privileges, send a request to lloyd@lmckenzie.com
* [FHIR resource and profile proposals](/index.php?title=Category:FHIR_Resource_Proposal "Category:FHIR Resource Proposal") - proposals for new resources & profiles
* [FHIR Profile authoring](/index.php?title=FHIR_Profile_authoring "FHIR Profile authoring") - Creating and maintaining FHIR profiles (see also [Profile Tooling](/index.php?title=Profile_Tooling "Profile Tooling"))
* [FHIR Change requests](/index.php?title=FHIR_Change_requests "FHIR Change requests") - Process for managing and resolving
* Guidelines
* [Fundamental Principles of FHIR](/index.php?title=Fundamental_Principles_of_FHIR "Fundamental Principles of FHIR")
* [FHIR Methodology Process](/index.php?title=FHIR_Methodology_Process "FHIR Methodology Process") - how the methodology is developed and maintained
* [Methodology Guidelines](/index.php?title=FHIR_Guide_to_Designing_Resources "FHIR Guide to Designing Resources") - Content and quality guidelines
* [Design Patterns](/index.php?title=FHIR_Design_Patterns "FHIR Design Patterns")
* [FHIR Comparison to other RESTful API specifications](/index.php?title=FHIR_Comparison_to_other_RESTful_API_specifications "FHIR Comparison to other RESTful API specifications")
* Resources
* [List server](/index.php?title=FHIR_email_list_subscription_instructions "FHIR email list subscription instructions") - discussions
* Discussion pages: [Active Discussions](/index.php?title=Category:Active_FHIR_Discussion "Category:Active FHIR Discussion"), [All](/index.php?title=Category:FHIR_Discussion "Category:FHIR Discussion")
* [FHIR Design Requirements Sources](/index.php?title=FHIR_Design_Requirements_Sources "FHIR Design Requirements Sources")
* [FHIR Resource Types](/index.php?title=FHIR_Resource_Types "FHIR Resource Types")
* [FHIR Resource Considerations](/index.php?title=FHIR_Resource_Considerations "FHIR Resource Considerations")
* [(old)](/index.php?title=FHIR_Governance "FHIR Governance") - governance discussion with bits of methodology mixed in (to migrate to other pages)
* [FHIR Terminology Service](/index.php?title=FHIR_Terminology_Service "FHIR Terminology Service")
* [FHIR Digital Signature Working Page](/index.php?title=FHIR_Digital_Signature_Working_Page "FHIR Digital Signature Working Page")
* WG FHIR pages
* [Patient Administration Resource development](/index.php?title=Patient_Administration_Resource_development "Patient Administration Resource development")
* [CDA to FHIR Samples Group](/index.php?title=CDA_to_FHIR_Samples_Group "CDA to FHIR Samples Group")
* [FHIR_Patient_Care_Resources](/index.php?title=FHIR_Patient_Care_Resources "FHIR Patient Care Resources")
## Organizational
* Governance
* [FHIR Governance Process](/index.php?title=FHIR_Governance_Process "FHIR Governance Process")
* [FHIR Governance Board](/index.php?title=FHIR_Governance_Board "FHIR Governance Board") (FGB)
* [FHIR Management Group](/index.php?title=FHIR_Management_Group "FHIR Management Group") (FMG)
* [Modeling and Methodology](/index.php?title=Modeling_and_Methodology "Modeling and Methodology") (MnM)
* [Work Groups](/index.php?title=FHIR_Work_Groups "FHIR Work Groups")
* [FHIR Escalation Processes](/index.php?title=FHIR_Escalation_Processes "FHIR Escalation Processes")
* [FHIR Ballot Process](/index.php?title=FHIR_Ballot_Process "FHIR Ballot Process")
* [FHIR Web Server Hosting Record](/index.php?title=FHIR_Web_Server_Hosting_Record "FHIR Web Server Hosting Record")
* Agendas
* **[Paris WGM](/index.php?title=FHIR_Agenda_201505_WGM "FHIR Agenda 201505 WGM")** (next meeting, May 2015)
* [Past Working Group Meetings](/index.php?title=Category:FHIR_Meeting "Category:FHIR Meeting") (list of agendas/notes)
* [MnM agendas](http://wiki.hl7.org/index.php?title=MnM_Schedule)
* [FGB Agendas & Minutes](http://wiki.hl7.org/index.php?title=FHIR_Governance_Board#Meeting_Information)
* [FMG Agendas & Minutes](http://wiki.hl7.org/index.php?title=FHIR_Management_Group#Meeting_Information)
## opensource project
* Testing
* [FHIR 公开测试服务器的测试报告](http://www.projectcrucible.org/)
* Lib
* [Ruby语言的FHIR模型 工具等](https://github.com/fhir-crucible/)

View File

@ -0,0 +1,80 @@
# FHIR概述
欢迎使用 FHIR 标准,它是卫生保健信息电子化交换的一种标准。这部分是对标准的概述,作为一个路线图,希望能帮助初次接触的读者更快上手。
## 背景
医疗保健记录越来越多的被数字化。当病人在整个医疗系统中转诊的时候,要求他们的病历能够获得、能够找到和能够理解。更深层次的,能够支撑自动化地临床决策支持和其他机器处理,要求数据是结构化的 并且是标准化的。(参考[卫生保健所面临的数字化挑战](change.html))
[HL7](http://hl7.org/)在过去20多年里一直致力于构建卫生保健数据交换和信息模型标准来解决这些难题。FHIR是一种新标准采用了其他行业的通用方法同时借鉴了在定义和实现 HL7V2V3,RIM 和 CDA 标准过程中所获得成功、失败的教训。FHIR可以单独作为数据交换标准来使用也可以和其他广泛应用的标准一起来使用(参考[FHIR与其他HL7标准的比较](comparison.html))
FHIR旨在不牺牲信息完整性的前提下简化开发和实现。它利用了现有的逻辑和理论模型为不同的应用程序间交换数据提供了一种一致的、易于实现的、健壮的机制。FHIR的内在机制使得其能够追溯到 HL7 RIM 和其他内容模型这就保证了与HL7之前定义的模式最佳实践间的保持一致毋须开发人员充分了解 RIM 和 HL7 V3 的其他衍生制品。(参考[FHIR与其他HL7标准的比较](comparison.html))
## 1.7.0.2 组件
FHIR 中最基本的组件叫做[资源](resource.html).所有可交换的内容都被定义成一个个资源。所有资源都拥有如下特征:
* 同一种[定义](resource.html)、[表达](formats.html)它们以及从[数据类型](datatypes.html)(最基本的可重用元素)构建它们的方式
* 同样的[元数据](resource.html#metadata)集合
* [供人可读的部分](narrative.html)
## 1.7.0.3 方法论
### 1.7.0.3.1 信息建模的方法
FHIR 的理念在于定义一个资源的基础集合要么利用它们要么相互结合来满足大多数常见的应用场景的需求。FHIR资源旨在定义绝大多数开发实现中通用的核心信息集合的信息内容和结构。如果需要的话有内在的[扩展机制](extensibility.html)来满足剩下的需求。
FHIR 的建模采用了一种组合式的方法论。相比而言HL7 V3 建模是基于“model by constranit”(参考[FHIR与其他HL7标准的比较](comparison.html)) 。对于 FHIR特殊的应用场景通常是通过利用[资源引用](references.html)整合资源来实现的。尽管对于一个特定场景,单独一个资源可能是存在价值的,更多的是对资源互相整合和裁剪来满足特定的需求。用来描述资源如何整合使用的两类特殊资源:
* [一致性声明](../infra/conformance.html)——描述一种实现中所暴露的交换数据的接口
* [规范profile](../infra/profile.html)——描述该实现中所使用的资源中定义的用以约束基数、可选性、术语、数据泪下和扩展的其他规则。
### 1.7.0.4 标准
基本上FHIR标准分为三大块
* 基础[文档](documentation.html)部分——描述了[资源是如何定义](resources.html)的,[数据类型](datatypes.html)、[编码](terminologies.html)的定义和[XML](xml.html) 、[JSON](json.html)格式的相关背景信息。
* [开发实现部分](../impl/implementation)——描述在[REST](../impl/http.html) 、[消息](../impl/messaging.html)、[文档](../impl/documents.html)和[SOA](../impl/services.html)中使用资源。
* [资源列表](resourcelist.html)——resourcelist.htmlFHIR中定义的所有资源的列表。其中又分为[临床类](../clin/clinical.html)、 [行政管理类](../admin/administration.html) 和[基础架构类](../infra/infrastructure.html)三大类。
资源有多种用途,从最基本的[护理计划](../clin/careplan.html)和[诊断报告](../clin/diagnosticreport.html)等临床内容到如[消息头](../infra/messageheader.html)、[一致性声明](../infra/conformance.html)等基础架构。虽然它们具有共同的技术特性但却以完全不同的方式来使用。注意毋须为了使用资源而必须使用REST。
## 1.7.0.5 如何入门
最好是快速阅读一下 [资源列表](resourcelist.html),对已经有了哪些资源有个感性认识,然后看一下[患者](../clin/patient.html)的定义来看看资源的定义是什么样的,接着读一下以下介绍背景信息的章节:
* [资源](resource.html)——资源是如何定义的
* 所有资源都有的[叙述性文本](narrative.html),以及[资源之间如何互相引用](references.html)
* [格式](formats.html)[XML](xml.html) 、[JSON](json.html)
* [扩展相关](extensibility.html)——标准能够保持简单的关键
* 如果你之前了解 HL7 标准(V2 V3 CDA)的话,[FHIR 与其他 HL7 标准的比较](comparison.html)也值得一看。
### 1.7.0.5.1 顶部标签
整个标准中都会看到这些标签,很多读者可能会遗漏:
![](../material/header-tabs.png)
[资源](resources.html)和[数据类型](datatypes.html)都是以一种类似XML的 易于阅读的方式来呈现的它们也有详细描述内容的正规定义。另外大多数资源映射到很多不同的格式如HL7V2HL7V3 RIM CDADICOM等。同时所有资源至少包含一个实例(有时候会有更多)适当的时候也会有描述它们如何在特殊情况下使用的profile规范。最后一些资源包含了 帮助开发人员理解它们背后的设计原理的小贴士/备注。
## 1.7.0.6 寻求额外信息和提供反馈
为了能够让更多读者看懂的同时FHIR标准是面向开发人员社区的——这些真正利用标准编写程序的人。为了满足开发人员社区的需求编辑人员力求标准行文精确减少在编写程序之前的阅读时间(然而这份标准并不如我们所想的那么简明扼要,有时候是医疗保健和现实世界的复杂度所致)。鉴于此,在开发过程中并不必要的信息,诸如原理、备选方案、一些争论点和将来的计划等并没有包含在标准里面。同样,开发人员时不时会发遇到标准不明晰或者不完整的清空。最终,会有一些情况,标准可能是错的,或者是对其进行修订以更好的满足开发人员的需求。
因此HL7提供了多种方法通过这些方法可以维护和获取一些额外的FHIR相关信息能够提供一些帮助响应一些变更请求。
### 1.7.0.6.1 评论
在每页底部,都有一个评论的部分,可以就特定章节进行提问和讨论。评论由 FHIR 编辑人员和HL7工作组来监管每个问题都会在一定的时间内给予答复。This content will occasionally be currated to ensure ongoing relevance, particularly if the specification is subsequently updated to eliminate confusion that may have spawned an initial comment.
### 1.7.0.6.2 FHIR Wiki
FHIR 项目团队维护着一个[wiki](http://wiki.hl7.org/index.php?title=FHIR)记录了开发过程、方法学和设计决策。开发人员和其他人员也可以参与到wiki中来提供一些暂未出现在标准中的指导和补充信息。注意 FHIR wiki上的内容不具有权威性与FHIR标准的一致性无关。同样一些内容可能也没有和最近的FHIR版本保持一致。
FHIR标准中的每个页面在wiki中都有一页内容。用以记录原理、决策点和其他与开发人员无关的信息。额外的页面包括[FHIR 方法论](http://wiki.hl7.org/index.php?title=FHIR_Development_Process)、[FHIR 设计工具的使用](http://wiki.hl7.org/index.php?title=FHIR_Guide_to_Authoring_Resources)等。要研究wiki的话建议从[首页](http://wiki.hl7.org/index.php?title=FHIR)开始.
### 1.7.0.6.3 正式变更请求
正式请求可以在[这里](http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemAdd&tracker_id=677)提交。对应的工作组会审核这些请求,并作出是否将其纳入到标准中的决策,其中包括了纳入到那个版本。
### 1.7.0.6.3 源码/参与机制的额外信息
除了上述机制HL7提供了一个 Stack Overflow 的标签邮件列表和skype聊天频道来提供对开发人员各个层面的全方位的支持。如何使用这些请参考[指令](http://wiki.hl7.org/index.php?title=FHIR#More_help_and_Asking_Questions)
© © HL7.org 2011+. FHIR DSTU (v0.5.0-5149) generated on Fri, Apr 3, 2015 14:36+1100.
链接:[试行版是什么](http://hl7.org/implement/standards/fhir/dstu.html) |[版本更新情况](http://hl7.org/implement/standards/fhir/history.html) | [许可协议](http://hl7.org/implement/standards/fhir/license.html) |[提交变更建议](http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemAdd&tracker_id=677)

View File

@ -0,0 +1,10 @@
# FHIR 简介
---
主要是介绍一些FHIR 缘起的大背景,以及产业界对其唱衰唱好的各种论调。
- [开发者眼中的 FHIR](/fhir-in-action/introduction/toreader.md)
- [FHIR 实现](/fhir-in-action/introduction/fhir-mplementation.md)
- [FHIR 概述](/fhir-in-action/introduction/fhir-overview.md)
- [FHIR 开发者指南](/fhir-in-action/introduction/fhir-dev-guide.md)
- [开放数据](/fhir-in-action/introduction/open-data-is-coming.md)

View File

@ -0,0 +1,339 @@
# 开放数据专题
有关医疗数据的开放标准的口水战和讨论早就开始了,这是因为美国方面的医疗病历数据主要掌握在 EPIC 的手上。
很多医院和医疗机构都在使用 EPIC 的产品,但 EPIC 的产品线又非常封闭,导致医疗机构之间的数据通信和交换都非常困难。
这个页面中的主要内容都在说 EPIC 和 CommonWell 口水战。
这场口水战的主要起因还是有关国会的医疗预算,同时要求 ONC 能够解决医疗系统的数据互联互通问题。EPIC 当然是不愿意放弃这块的。
当我们现在再次重温这篇页面中的内容的时候已经是 2024 年了。现在来看在互联互通上已经有了很大的进展。
相对美国有关医疗系统的扯皮来看,我们国家的医疗系统起步比较晚,没有技术负担,相对美国来说,我们的医疗系统发展更加迅速和智能化。
但也面临不少问题,其实也是标准化的互联互通问题,相信随着 FHIR 的标准的持续推进,在后续的互联互通难度应该是在逐步下降的。
## 立法进一步推动美国联邦政府开放更多数据
在2015年4月16号一个因废止了Medicare中过时的根据可持续增长率来计算医生收入的公式而出名的Medicare Access and CHIP
Reauthorization Act (MACRA) 正式成为了法律, 有人称此举给Affordable Care Act 法案的 Medicare Data Sharing
Program 注入了一剂强心剂更有人称其中的105章节要求政府将更多的 claim(医保报销)数据开放给准入机构,更是给中小型医疗机构带来了春天。
```
1. 由于平价医疗法的存在HHS也就是美国卫生部公开了一部分Medicare claim数据给准入机构这些机构利用医保数据和商业化数据进行数据分析来获取
如何更好的达到要求的医疗质量和效率等指标来指导实践。由于此举风险甚高议会持保守态度但很快大家都意识到这样做远远不够故在MACRA的105章节中放开更多数据
2. 其中要求HHS Secretary不仅开放Medicare数据也开放Medicaid和CHIP数据。这样子系统中的医保数据将会翻倍能够支持更加复杂的数据分析。
3. 尽管开放多少数据开放不开放的决定权握在了HHS Secretary手里但还是有很大希望的毕竟Medicare的医保数据已经开放了2年如果够快的话Medicare每年应该能够开放
```
### 背景资料
ACA平价法案
```
美国总统奥巴马上任后积极推动医保改革去年立法的《平价医疗法》当地时间12日却被上诉法院裁定违宪令医保改革前路茫茫。分析指表面上共和党明显打赢一仗但由于法院仅裁定强制参保条款违宪其余部分仍然有效最大输家其实是医保公司民主党不但未必介怀还可能对裁决乐观其成。
据报道目前美国约有5000万人没有基本医疗保险医院及纳税人被迫每年代为支付高达430亿美元(约合人民币2749亿元)。民主党控制的国会去年3月通过立法规定由2014年起美国所有18岁或以上的民众必须终生购买保险否则会遭到税务惩罚政府则会给予无力付款的民众津贴。
据介绍强制参保条款是奥巴马医改法案的重点能使3200万未投保的民众被纳入医保“保护伞”下令美国全国医保覆盖率提升至95%,并要求保险公司接受已患病的民众投保。
分析认为,美国民主党其实并非很支持强制投保,最支持的是可赚大钱的保险公司。保险公司要求全民强制参保,才愿意接受早已患病的投保人。
民主党当初为平息保险公司的反对声音,支持全民投保只是权宜之计。若该条款最后被删除,其余部分仍有效,保险公司将被迫继续接受患病者的投保,民主党也可达成全民医保的目标,民主党何乐而不为?
```
美国政府的开放数据集。自从Data.gov开放以来美国已经公开了超过八万五千个政府数据集并提供免费下载。
有关美国联邦政府的数据开放计划,请参考:
* https://project-open-data.cio.gov/
* https://github.com/project-open-data
## epic 和 CommonWell 之争
在美国的医疗病历领域EPIC 是最封闭,最不愿意开放的公司。毕竟数据是这个公司的所有业务基石,公司的数据和软件生态系统非常封闭,当数据离开了公司提供的平台后完全无法运行。
所以 EPIC 是数据互联互通最大的障碍。
EPIC 使用的 Caché 数据库,这个数据库的存储非常封闭,可恶的是 EPIC 在数据库的基础上又开发了一套自己的的数据库实例,虽然底层还是使用的
Caché 数据库,但上层和 API 已经被完全重构了。
CommonWell 健康联盟是一个由医疗IT公司组成的行业协会过去三年来一直致力于在其成员的技术之间建立数据互操作性。
Cerner, McKesson, Allscripts, athenahealth, Greenway 和 RelayHealth 这几家公司宣布成立了相关的联盟用于对抗 EPIC。
联盟的官方地址为https://www.commonwellalliance.org/
相关参考链接:
* http://www.commonwellalliance.org/news/commonwell-health-alliance-announces-member-expansion-plans-for-2015/
CommonWell Health Alliance today announced the commitment of five of its health IT vendor members—athenahealth, Cerner,
CPSI, Greenway Health and McKesson—to actively deploy CommonWell services to health care provider sites nationwide
throughout 2015.
Already, more than 60 provider sites are live on CommonWell services across 15 states including: Alabama, Delaware,
Florida, Illinois, Indiana, Kansas, Massachusetts, Mississippi, Nebraska, North Carolina, Ohio, South Carolina, South
Dakota, Texas and Washington. CommonWell expects 2015 deployments to enable at least 5,000 provider sites to be live on
the services nationwide. CommonWells built-in services include patient identification, record location, patient privacy
and consent, and trusted data access.
### 缘起
2014年7月17号在[众议院能源和商务委员会的小组委员会通讯技术和健康 House Energy and Commerce Committee's subcommittee on Communications and Technology and Health](https://energycommerce.house.gov/committees/subcommittee/health)
的听证会上,从医生成为议员的 Rep. Phil Gingrey 指责 EPIC 道:
```
一些电子病历的供应商的系统本身就在阻碍数据的共享和交换就不应该拿到Meaningful Use incentive计划的钱。但根据RAND的一份报告刺激计划的240亿美金中的一半以上都被
Epic公司拿走了可Epic玩的是自己的封闭平台这是HITECH的初衷么纳税人的钱是这么花的么。
无独有偶在RAND的报告中建议国会“取消那些需要额外组件、费用和定制才能够实现数据共享的医疗信息化产品的认证资格”。同期的一份研究中也指出Meaningful Use program 计划
第二阶段的数据共享的架构是不够健壮的,不足以支撑数据的共享。
```
原文如下
```
Electronic health record vendors--particularly Epic--may not deserve Meaningful Use incentive money because their systems hinder data sharing, according to physician-turned-lawmaker Rep. Phil Gingrey (R-Ga.).
In a July 17 hearing of the House Energy and Commerce Committee's subcommittee on Communications and Technology and Health, Gingrey (pictured) questioned whether the nation is currently on a path of interoperability or whether changes to the law need to be made. He expressed concern that according to a recent RAND report, more than half of the $24 billion spent by the Meaningful Use program has gone to Epic, a vendor operating a "closed platform."
Pointing out that the committee has jurisdiction over the Office of the National Coordinator for Health IT and the HITECH Act--which created the Meaningful Use program--Gingrey said that if the RAND report is true, "we have been subsidizing systems that block information instead of allowing for information transfers, which was never the intent of the [HITECH] statute.
"It may be time for this committee to take a closer look at the practices of vendor companies in this space given the possibility that fraud may be perpetrated against the American taxpayer," he added.
The hearing was focused on how healthcare and technology can accelerate the pace of cures in the U.S., which is an initiative of the committee.
Gingrey is not alone in his concern about EHRs' lack of interoperability. The coalition Health IT Now, buoyed by the RAND report that decried the lack of interoperability among EHRs, recommended that Congress "decertify systems that require additional modules, expenses, and customization to share data," and to investigate business practices that prohibit or restrict data sharing in federal incentive programs.
Another recent study revealed that the current architecture for data exchange required by Stage 2 of the Meaningful Use program doesn't allow for robust patient sharing.
```
### ONC发布互操作性路线图
关于这个10年的互操作性路线图,更多中文信息可参考
1、[ 【OMAHA】美国联邦政府医疗信息化战略规划2015 - 2020](https://www.isharkfly.com/t/2015-2020/15499)
2、[一张图看美国互操作性路线图](https://www.isharkfly.com/t/topic/15500)
3、[ONC发布HIT互操作路线图 助推精准医学计划](https://www.isharkfly.com/t/onc-hit/15501)
某个组的老大如是说“如果我们能够让不同的系统能够互相'说话',那已经是相当牛逼了”
原文如下
```
"If we just get the systems themselves to talk to each other, that would be a huge accomplishment," Health IT Policy Committee member Paul Egerman, former CEO of eScription, said at the meeting. "Perhaps we're making this harder than we need to make it, and it's already pretty hard."
尽管局部范围已经实现了一定程度的互操作性,但大规模的应用还是很大的问题。
while interoperability has increased, widespread interoperability remains a challenge. The report identifies several barriers to interoperability, including unchanged provider practice patterns, the lack of standardization among EHRs and the lower priority placed on EHRs by providers who are ineligible for the Meaningful Use program.
```
### Omnibus bill keeps ONC funding at same level as 2014
2015 年的 Omnibus 法案成为导火索
```
The Omnibus Appropriations bill that passed Congress over the weekend will fund the Office of the National Coordinator for Health IT at the same level as last fiscal year with a budget of just under $60.4 million. After the bill passed the House last week, the Senate approved it Saturday night.
Additionally, the bill grants $14.9 million to the Federal Office of Rural Health Policy within the Health Resources and Services Administration to administer the Small Rural Hospital Improvement Grant program for quality improvement and adoption of health information technology. It also awards the VA $3.9 billion in IT funds, $200 million more than FY2014, including $344 million for the modernization of VistA and the development of an interoperable system with the Department of the Defense.
Of the total IT budget, $548.34 million is earmarked for IT development, modernization and enhancement.
```
国会敦促 ONC :要专注在互操作性上。
在国会通过2015 omnibus appropriation
bill法案的同时提交的[报告](https://www.isharkfly.com/t/division-g-department-of-labor/15502)中国会很生气敦促ONC
“”要合理使用你们手中的认证的权利来保障合格的产品能够医疗机构和人民群众带来价值。只给那些满足我们的认证标准的且没有阻碍区域医疗(
医疗信息交换)的产品给予授权,对于阻碍信息共享的产品要收回执照。
```
"[U]se its certification program judiciously in order to ensure certified electronic health record technology provides value to eligible hospitals, eligible providers and taxpayers. ONC should use its authority to certify only those products that clearly meet current meaningful use program standards and that do not block health information exchange. ONC should take steps to decertify products that proactively block the sharing of information because those practices frustrate congressional intent, devalue taxpayer investments in CEHRT, and make CEHRT less valuable and more burdensome for eligible hospitals and eligible providers to use."
```
同时在报告里要求ONC90天内提交一份报告分析一下目前信息阻塞问题的严重程度要有个大概的厂商、医疗机构的数目以及解决问题的方案。
### 信息化厂商和医院都是信息阻塞的罪魁祸首
这里就是上面 ONC 根据国会的要求提交的报告具体内容请参考https://www.isharkfly.com/t/onc/15498
在这份报告中指出:
1、医院或厂商通过收费来控制转诊和加强自己的市场占有率
A common charge is that some hospitals or health systems engage in information blocking to control referrals and enhance
their market dominance
2、厂商反馈 原因很多啦 比如说HIPAA 但作业中指出都是借口 和HIPAA压根没多大关联
It has been reported to ONC that privacy and security laws are cited in circumstances in which they do not in fact
impose restrictions
作业中给出的解决方案:
1、Strengthen in-the-field surveillance of ONC certified health IT tools, which was proposed in the certification
requirements accompanying the Stage 3 Meaningful Use rule
2、Constrain standards and implementation specifications
3、Promote better transparency in certified health IT products and services that would "make developers more responsive
to customer demands and help ameliorate market distortions" that lead to vendor information blocking
4、Establish governance rules deterring information blocking, which the report notes is addressed in ONC's
interoperability roadmap
5、Work with the U.S. Department of Health and Human Services Office for Civil Rights to ensure healthcare stakeholders
understand HIPAA privacy and security standards, particularly those related to information sharing
6、Coordinate with the HHS Office of Inspector General and the Centers for Medicare & Medicaid Services on information
blocking as it relates to physician self-referral and the federal anti-kickback statute
7、Refer illegal business practices to law enforcement agencies
8、Work with CMS to provide incentives for interoperability while simultaneously discouraging information blocking
9、Promote competition and innovation in health IT, which the Federal Trade Commission recommended in its comments on the
interoperability roadmap
但看了总结就知道 美帝也是各种部门互相扯皮呀这种东西往后10年看有起色不。
当我们看到这篇文章的时候已经是 2024 年了,在 FHIR 的推进下,各种工作其实也是在有条件的进行中。
我们认为这里面推动阻力最大的莫过于 EPIC 了。
```
"While important, these actions alone will not provide a complete solution to the information blocking problem," the report's authors say. "A comprehensive approach will require overcoming significant gaps in current knowledge, programs and authorities that limit the ability of ONC and other federal agencies to effectively target, deter and remedy this conduct, even though it violates public policy and frustrates congressional intent.
```
### 口水仗
有关 EPIC 和 CommonWell 的口水战在 2015 年就开打了http://www.healthcareitnews.com/news/epic-vs-commonwell-showdown
Senate HELP Committee Tuesday 2015年3月17日的组委会例行会议上
在听证会的问答环节参议员Senator Tammy Baldwin, D-Wisconsin问 为什么Epic 没有参加 CommonWell Health Alliance
Epic 的主管互操作性的头Peter DeVault说了如下一段话引发了CommonWell Health Alliance的反击
```
"When we were approached by them and asked to join, we were told that it would be multiple millions of dollars for us to join and that we would have to sign an NDA.To us, the only reasons to have an NDA are if they're going to tell you something that otherwise they wouldn't want people to know" - which he said could include the possibility they may sell data downstream or wanted to ensure there were no intellectual property conflicts.That lack of transparency didn't sit well with us
```
同时还不饶人的嘲讽 你丫们只是嘴上说说 雷声大雨点小。
CommonWell至今成立2年目前只涵盖了1000个医生 和Epic的care Everywhere的10万医生简直高下立判
```
DeVault also underscored CommonWell's low participant numbers in its interoperability project so far which he called an "aspiring network," noting a stark difference when compared to Epic's Care Everywhere network.
```
CommonWell联盟随后在Healthcare IT News发表了联合声明
```
We are committed to openness and transparency," the statement read. "Accordingly we publish our services and use case specifications, along with our nominal membership and service fees on our website for everyone to see.
```
那么Epic要入会 大概要每年缴纳多少钱呢 根据目前CommonWell会员费和服务费用标准结合Epic2014年的年收入18亿美元要掏
125万美元annual subscription fee和 $50,000 to $90,000 in annual membership dues 。
就是 2015-03-18 日 athenahealth CEO Jonathan Bush 在 twitter上对 Epic 的 CEO Judith R. Faulkner 进行了高调嘲讽。
![](https://cdn.isharkfly.com/com-isharkfly-www/discourse-uploads/original/2X/7/725691b8b156724972a47cbbb29dbffc36172ec6.jpeg)
Cerner —— 行业老二也发话了
```
His "rhetoric is a slap in the face to many parties working to advance interoperability," according to a statement released by Cerner officials shortly after the committee hearing. "It was discouraging to hear more potshots and false statements when it's clear there is real work to be done. We're committed to CommonWell as a practical, market-led way to achieve meaningful interoperability
```
梗在这里 2013年 HIMSS 上 Epic 和 CommonWell 就有口角。
```
At that HIMSS13 announcement, athenahealth CEO Jonathan Bush 说 大家都可以加入哟
emphasized that anyone was invited to CommonWell even a vendor of "epic proportions."
In a subsequent interview, Healthcare IT News asked McKesson CEO John Hammergren whether that invitation was dangled only because the founding companies suspected Epic wouldn't bite.
"We'd like them to bite! We want them to bite," said Hammergren. "I'm hopeful that they will see it the same way we see it."
```
但 Epic CEO说 完全不知情,这帮人居然想背后地里阴我们,手够黑的啊。
```
But Epic CEO Judy Faulkner noted that her company wasn't asked to join before the announcement. "We did not know about it. We were not invited," Faulkner told Bloomberg back in 2013. "It appears on the surface to be used as a competitive weapon, and that's just wrong. It's wrong for the country."
```
对于行业内愈演愈烈的竞争所引发这场闹剧,围观群众也有话说:
1、各位看官和Epic签合同要慎重啊 且要是Epic-to-non-Epic能达到Epic-to-Epic 的90%的功能,"哥就表演吃翔"
2、路人乙嘲讽到Epic到底是如何腆着脸皮说all of our systems can talk to each other
3、入会费是不是有点多
4、Epic does not need to join CommonWell. CommonWell needs to join Epic.
5、CommonWell sounds like a group of union thugs who want to strong-arm their way into other vendors' businesses
6、CommonWell or is it CommonHell? Later seems to be more appropriate.此人称Epic很好合作 方案也性价比高Stop creating
mindless standards organizations with a scheme to collect additional revenues from licensing. Healthcare organizations
dole out enough on their EMRs to these vendors and they don't need these vendors charging nickel and dime on every petty
thing that gives patients control of their health information
"我深深的表示赞同"
7、It just doesn't seem right that a private company pulling down $1.8B in revenue should be able to dictate
interoperability. The government needs to step in and make sure all of these companies play well in the sandbox. Greed
stands in the way of a national clinical data repository that researchers could use to find treatments and cures for
diseases that have plagued us for decades.
问题不存在一个厂商上 此人观点有理
8、Joining CommonWell doesn't seem like a great business opportunity if after two years they only have 1000 doctors live
on it. Epic seems to understand the fundamentals of sharing patient data if they have 100,000 doctors on their version.
My guess is that CommonWell is floundering and they want Epic in there to help them out. If they can also take some digs
at Epic for not joining in the meantime - all the better in their mind.
The healthcare market will drive the need for interoperability. I don't think getting the government involved will help
anything.
9、What would be interesting to know is how many of Epic's 100,000 physicians are using a product other than something in
the Epic family.
Epic excels at interoperability between their own products, but what is their track record when connecting to someone
outside the family, so to speak? Their numbers may be impressive, I don't know. But I do know that the huge challenge
CommonWell has is interoperability across disparate vendors and products.
10、It seems to me that CommonWell is primarily a marketing "gimmick". Aids and standards for inter-operability e.g.
LOINC, CLSI standards, and other accepted nomenclatures have existed in the marketplace for some time. We probably have
enough standards but many vendors simply pay "lip service" to them. Such a "collaboration" among competitors may be a "
surface phenomenon" with relatively little substance.
11、对第10条的回复 CommonWell is a response to Epic's market share and market power by vendors that heretofore did not
feel compelled to cooperate with each other on data exchange. Epic dramatically dominates the large HCDO/ Academic
Medical Center market and is viewed as almost unstoppable. As Epic conquers the large market, it will target the
mid-size market - probably taking advantage of a cloud service at some point in time. This probably best explains why
Epic doesn't want to join CommonWell - they understand the strategic alignment and competitive response that CommonWell
represents.
12、It does seem a bit childish to see these types of exchanges between behemoths of the industry. However, I do wonder
why Epic would have to sign an NDA to participate in a joint effort to share and propagate openess.
### Epic 投降了
Epic CEO Judy Faulkner 在每年度最盛大HIT行业会展也就是 2015 年的 HIMSS15 大会上宣布直到2020年之前咱大EPIC是不会再收大伙钱了。
其实athenahealth和Cerner这俩货也是不久之前宣布他们也不收费。
https://www.healthcareitnews.com/news/epic-latest-drop-fees-data-exchange#:~:text=%2Dbased%20health%20IT%20giant%20Epic,the%20Milwaukee%20Business%20Journal%20reports.
群众观点:
1、up-front predictable cost and a pay-per-use model两种付费模式的区别而已钱总是会出的
2、市场的不成熟导致没有有效的激励方式来促使信息的无缝免费流动。而能因为厂商收取服务费用就认为是某个厂商作恶。要解决的是到底谁来掏钱的问题
3、不额外收钱的话软件的成本、维护费咨询费必然要上涨羊毛出在羊身上
http://www.healthcareitnews.com/news/epic-latest-drop-fees-data-exchange
### 思考
国内最早喊互操作性的应该是李包罗老爷子了从最初引入这样的概念至今大概也有10来个年头了不管是学术界还是工业界这些年来沿着的一条路是说想要给复杂的医疗领域定义出一种通用的one-fit-all的能够描述整个医疗领域的模型
进而演化出一种可以用于不同系统间交互数据的通用格式和统一的医疗术语,也就是所谓的互操作性标准。
这些年也有人在提学习型的医疗信息化系统的建设提精准医疗大喊互联网医疗的口号但这些目标的实现都离不开数据离不开鲜活的在不同系统间流动的数据就像阿里、京东、腾讯、amazon一样没有各部门间数据的无缝整合
它们是不能提供大家每天都在享受的这些服务的。
近几年不管是google还是豌豆荚都在说一个“应用内搜索”的东西说白了就是想把接入各自平台的系统的数据格式标准化这样子就可以点开具体的应用来搜索查询信息但似乎也没有什么进展
对于如日中天的互联网应用来讲对于宇宙第一的google来讲尚且很难突破的东西反过来看医疗行业业务只会更复杂业务系统的成熟度只会更低似乎互操作性的口号
我们喊得太早了能从美帝、互联网厂商身上学到的是未来势必在国内的HIT圈要成长出一两家如Epic这样的公司在自己封闭的平台中
实现各级医疗机构的信息无缝流通,只有这样的巨无霸,通过自己所收集的患者全生命周期的数据链,利用医疗大数据的应用打造出优质的医疗服务来服务大众,但有没有其他实现互操作性的路径呢?
Epic与IBM watson的合作 是否预示着实现互操作性的另一条路
智能的解析各种异构的数据源中的数据 https://www.healthcareitnews.com/news/epic-watson-work-interoperability 。
**API 能否拯救 HIT 的相关探讨**
针对有关内容的探讨,我们收集了一些内容,请访问下面的链接。
* http://geekdoctor.blogspot.nl/2014/12/kindling-fhir.html
* http://xmlmodeling.com/2014/12/jason-argonauts/
* http://xmlmodeling.com/2014/10/jason-task-force-final-report/
* http://argonautwiki.hl7.org/index.php?title=Main_Page
* https://www.healthwise.org/blog/apps-apis-positive-step-for-patients.aspx
## 中国数据互联互通
相对美国有关医疗系统的扯皮来看,我们国家的医疗系统起步比较晚,没有技术负担,相对美国来说,我们的医疗系统发展更加迅速和智能化。
### OMAHA 联盟
浙江数字医疗卫生技术研究院简称“数研院”imit是中国首家致力于数字与信息化技术在医疗卫生健康服务领域研发与应用的专业性非营利研究机构NPO/NGO

View File

@ -0,0 +1,53 @@
# 对 FHIR 的认识
互联网医疗在过去的一年里如火如荼希望大家能够一起来汉化和开发FHIR相关的产品。
[FHIR Fast Health Interoperable Resources](https://hl7.org/fhir/) 是由HL7创建的新一代标准框架.FHIR 整合了 HL7 V2,V3 和 CDA
的优点,同时利用了最新的Web标准,紧紧围绕着 implementability 可实现性。
FHIR 解决方案是基于一些称之为“资源”的模块化组件的. 这些资源可以很容易的组装进生产系统中,以已有方案的一小部分成本来解决实际的临床和管理上存在的问题。
FHIR 适用于多种场景– 智能手机APP、云平台上的通信、基于EHR的数据共享、大型医疗机构内服务器通信和其他。
大多数在HIT这个行业浸淫略久的人都听到过HL7的字眼HIT 行业的标准不外乎有2个目的交互共享数据(HL7
V2消息V3消息CDAX12,共享文档规范诸如此类),表达医疗行业的知识(
各类术语字典数据集数据元标准ArdensyntaxCDSCGELLO诸如此类)
而FHIR应该归属于第一类与它的前辈不同的是它抛弃了既往顺着发展了10多年乃至于20年的那块田(
封闭又自恃过高,怎么说这点呢,所有的标准文件都有自己独特的脱离了整个软件行业的编辑器生成,这些模型也不能为其他通用型软件所读取,最可恨的是没有配套的各种开源库开放给大家试错,降低学习成本,恶心的是居然个破标准还要收费)
也就是在上世纪90年代末XML在整个软件领域刮起一阵风到处都在说系统集成时应运而生的V3消息CDA等毫无疑问它们都是为不同厂家的不同系统之间交换数据而生的而它们的下场都很惨用现在的话说都不够敏捷学习成本过高迭代也不够快。
在 FHIR 卷土重来的时候就把基调定好了,思想上这次要全面拥抱互联网技术,用通用的互联网技术来做原来没有成功的事情,仍然还是想实现医疗健康领域数据的无缝流动,打通整个数据闭环。
它的诱人之处我认为有如下几点:
1、过去的很多年美国人造了各种各样的标准国际友人也造了各式各样的轮子来解决上面的问题最近的2-3年里很多人抛出了这样一个问题能不能用同一种模型经过适当的演化就能表达医疗数据(
电子病历、健康档案、个人健康记录),又能表达医学知识(临床指南类决策支持用的知识,质控指标类的知识)
就目前FHIR发展的现状来看这是一个还不错的选择。有很多这方面的尝试美国的ONC最近也在这件事上砸了些钱希望能推动的更快一些。
2、拥抱互联网技术。卫生部这几年在推的区域平台、医院平台的技术点在我看来离现如今的互联网技术太远了作为已经被抛弃的SOAP流的SOA架构的残留物着实没听到在BAT等企业有何应用最近几年在人人学Amazon的同事新浪、京东等一批国内企业都在推一个叫open
API 或者是restful api或者叫HTTP API的东东以此来解决各自内部千千万产品间、产品内部的数据流动的问题简而言之就是以一种方式圈定某个领域的业务对象每种对象都使用同样的方法来实现一些功能类比到厨艺的话就是说约定好如何区分食材每种食材都有哪些烹饪方法这样子整个医疗领域就大约有100-200种资源(
最小的信息单元,当然这里面的粒度的拿捏很是讲究)用到的“烹饪方法”就是HTTP协议定义好的(诸如put/post/get等)。
数据本身的表达格式也从原来V2 V3单纯的EDI格式、XML格式演化到了目前比较流行的JSON以后或许还会演化出其他更为适合的方式。
这件事情一方面降低了学习认知整个标准的门槛,另一方面即使不使用它所规定的格式,顺着这样的思路,你也能解决一些问题。
这里的问题不单单是之前它的老前辈(v2\v3\cda)所更care的产品与产品间的数据交换数据共享你也可以借此实现产品内部的功能(京东的李大学总裁就介绍过它们在这方面的一些探索和实践)比如面临的移动端和PC端开发时功能复用的问题。
当然也有人会问这东西能作为数据的存储模型来用么这个问题是HL7 V3 RIM CDA所没能很好的解决的问题它们的抽象程度太高了但时代变了Nosql数据库现在已经有很多可供选择如果你要使用关系型数据库的话也有一些这方面的探索可供参考。
3、尽管国内目前关注度不够但在著名的代码托管平台Github上已经有大量的各种编程语言(java c# dephi javascipt swift等)
、各种平台可用的一些开源代码有适合PC端的也有适合移动端的这是很喜人的。
医疗领域的信息化是非常有前途的方向,但无奈的是北美的医疗信息化和病历方面的处理被深度绑定在 EPIC 这个公司上。
这个公司使用的技术已经算是非常古老的技术了,还在使用 M 语言。这个非关系数据库诞生在 R 数据库设计之前,目前这个这个公司在标榜说自己是非常先进的非关系型数据库。
说实话,经过一些研究发现,这个数据库实在是无法和现在的开放数据环境进行匹配,对比当前使用比较多的 NoSQL 数据库来看,这个数据库也实在太封闭了。
不管怎么 FHIR 的出现,为医疗系统中的数据互联互通提供了一个新的发展方向,对推动相关行业的发展还是有很多好处的。
## 联系我们
访问: https://fhir.isharkfly.com/#/CONTACT 页面中的内容来和我们取得联系。
推荐访问社区,并在社区中留下您的足迹。

View File

@ -0,0 +1,14 @@
# Naming Conventions
In simple terms, a naming convention refers to a framework used for naming your files in a specific way.
## Classes
Class names should be nouns, in mixed cases with the first letter of each internal word capitalized. Interfaces names should also be capitalized just like class names.
## Methods
Methods should be verbs, in mixed case with the first letter lowercase and with the first letter of each internal word capitalized.
## Variables
Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.
## Packages
The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, like com, edu, gov, mil, net, org.

5
package.json Normal file
View File

@ -0,0 +1,5 @@
{
"dependencies": {
"yarn": "^1.22.19"
}
}