FHIR临床用户入门

来自HL7ChinaWiki
Yangzuo讨论 | 贡献2016年1月21日 (四) 12:08的版本 (导入1个版本)

(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)
跳转至: 导航搜索

注释:在下一次投票通过之后,将会把本页面的内容编入FHIR技术规范本身当中。

对于以网络为中心工作的技术人员来说,理解作为技术规范的FHIR,是件轻松的事情。然而,FHIR的呈现形式全然以技术为中心,如果您不是一位对各种网络技术有所理解的技术人员的话,要弄清FHIR究竟是什么以及它如何发挥作用,可能就不是那么显而易见的事情了。不过,您也不必弄清这项技术的网络方面——作为FHIR基础的那些思想和概念真的相当简单而明了。本页面将采用一种简单的类比,来解释各种系统与FHIR之间究竟是如何交互的。我们把它们之间的这种交互方式/手段称为“应用编程接口(Application Programming Interface,API)”。如果您明白了这一点,那么,对于FHIR技术规范,您就有了足够的了解,可以去仔细审阅那些对于临床医生来说真正重要的事情,即种种FHIR资源的临床内容。

理解API

这里,我们不妨把FHIR比作一个文件柜或者说档案柜。这个柜子上有一系列的抽屉,并且每个抽屉上都贴有表示其中信息类型的标签。在每个抽屉里面,又有一系列带有编号的文件夹,分别代表着互不相关的信息包。每个文件夹里又分别夹着一张纸,而纸上则印有一张表单,其中填写着标准的一套信息。FHIR服务器负责批准对于该文件柜的使用权限,而客户端则可以请求它执行许多如下所示的关键操作:

  • 搜索(search):彻底对所有的文件夹进行搜索,找出那些符合特定一套搜索条件的东西
  • 读取(read):获得相应抽屉之中某一特定文件夹的一份副本
  • 创建(create):向相应合适的抽屉之中添加一个新的文件夹(且带有新的编号)
  • 更新(update):更改特定文件夹之中的内容
  • 删除(delete):从相应抽屉之中去除某个特定的文件夹(或者更准确地说,是将其隐藏起来)
  • 历史(history):获得某一特定文件夹、特定抽屉或整个系统的历史(好吧,并不是个普通的柜子——比作计算机是不是更好些呢?)
  • 交易(transaction):为服务器一次性地提供所要加以更新的一捆文件夹

在FHIR生态系统之中:

  • 文件柜(Filing Cabinet):FHIR服务器
  • 抽屉(Cabinet Drawer):某种资源类型,如患者资源Patient、情况资源Condition、观察结果资源Observation
  • 文件夹(Folder):特定资源类型的某个具体实例,如患者“John Smith”或情况“John Smith的哮喘”

利用资源分子构建实用的临床系统

每种资源之中都含有少量高度聚焦的数据。单独一种资源要表达的信息并不多,但许许多多非常微小的资源汇集起来,可以造就出有效实用的临床记录。信息系统会将用户所采取的那些行动(如查找患者的病历,记录患者的病史等等)分别映射到那些针对相应资源的操作之上。

这些资源之间彼此相互链接,而通过这些链接关系,就建立起了一个信息的网络,总体上则代表的是一份健康档案(或者说,至少是其实用的组成部分)。在所定义的这些链接关系的基础之上,各种资源即可链接到其他的资源,而负责处理健康档案的临床系统则可以利用这些链接关系来确定,对于特定的任务,它们究竟需要哪些资源。

基于FHIR的系统的能力是由相应的那些资源究竟能够表达什么来确定的。那么,从临床的角度来说,这些事情定义的就是临床记录:

  • 所定义资源的那些种类
  • 这些种资源的数据内容、关于其中数据的规则,包括术语集究竟编码什么东西
  • 这些种资源如何彼此相互链接起来
  • 您如何才能搜索信息

待办事项:在此,我们希望放上一副示意图,显示这些资源到底是如何相互关联在一起的——但是,这样一副图的个头过于庞大,难以使用。不过,您可以访问这个页面,看看按类别整理编排出来的这些资源。

FHIR资源的描述方法

要理解FHIR资源内容,您就不得不学会阅读FHIR资源的呈现形式。作为起步指导,如下是个极其简短的教程:

对于每种FHIR资源,都是从6个方面来加以描述的:

  • 关于其预定用途的 适用范围声明(scope statement)、规则及注释
  • 资源内容的简要图解 (diagrammatic summary)
  • 关于资源内容的XML样声明
  • 术语集绑定(terminology bindings)列表(什么元素采用什么代码)
  • 关于数据的规则列表
  • 可供您搜索之用的筛选条件(criteria,判断准则)列表
  • 例如,就让我们先来看看患者资源Patient

适用范围声明

该图描述的是预期要如何使用FHIR资源。

Fhir-clinical-scope.png

简要图解

Fhir-clinical-uml.png

这幅简要图解显示了FHIR患者资源Patient之中所包含的所有标准数据元。其中,每个数据元分别都有一个名称、类型(表示其中可以表达什么)、关于其出现的最少与最多出现次数(min..max)的规则以及术语集绑定(参见下文)。

注释:作为一种概括形式,该图之中并没有显示数据元的定义——如果想要具体查看定义,可以将鼠标指针放在相应的数据元名称上,或者也可以单击其名称(如性别数据元的名称"gender")。图中,每个数据元名称(字段名称)的长度都不足以进行完整的描述,因此,一件很重要的事情就是阅读数据元定义。另外,您还可以单击每个数据元名称右侧的数据类型(如人员姓名数据类型HumanName),查看该数据类型的技术定义;或者,亦可参阅下文附录当中的表格。

简洁的XML样表达形式

Fhir-clinical-xml.png

这一部分当中所显示的信息与上面的简要图解几乎一样,只是这里还额外包含了少量用于描述相应数据元的词语。其实,这应当已经足以理解相应数据元的功用,尽管您仍可以单击数据元名称,去看看相应的完整定义。单击绿色字体的‘数据类型’,则可以查看相应数据类型的详情。例如,患者姓名的数据类型为人员姓名‘HumanName’,因此它其中就会含有姓氏、名字等等。

注释:FHIR项目团队在处理细节信息的时候,也会利用这些图表和XML样表达形式来进行定位和导航。

术语集绑定

术语集绑定(terminology binding)部分旨在规定,对于特定字段,究竟可以采用什么种类的代码(比如说“对于诊断代码,请采用SNOMED CT”):

Fhir-clinical-tx.png

对于每个采用编码型取值的数据元,相应的术语集绑定之中包括一项英文定义、一条对用于描述实际代码列表的特定取值集合的引用(或者说引用关系)以及一个绑定类型。可能的绑定类型包括:

  • 固定型(Fixed) – 只能采用相应引用当中所规定的那些代码——不允许采用任何其他代码(这就是说,大家都完全同意如此规定——但这种情况并不常见)
  • 不完整型(Incomplete,不完全型) – 如果合适的话,应当采用相应引用当中所规定的那些代码,或者亦可采用别的某种代码。
  • 示例型(Example) – 所规定的那些代码仅仅为示例,旨在表明究竟期望什么样的代码。

关于数据的规则

Fhir-clinical-rules.png

大多数规则都相当简单——比如,在当前的例子中,如果列出的是一个联系方式contact,那么,就必须为其提供一些细节信息。每条规则不但备有一项英文定义,同时还有一项对计算机来说有意义的(或者说便于计算机处理的)描述。

FHIR资源搜索规则

最后,每种资源还定义了一套“搜索参数(Search Parameters)”。这些参数是一些用于操纵控制FHIR服务器搜索操作的规则。例如:

Fhir-clinical-search.png

这些参数是预期各种系统对FHIR资源进行搜索时所能够采取的方式。它们与临床方面直接相关——比如,您希望能够依据什么来查找这些资源之一?如果您要查找特定患者的话,您又会如何搜索这位患者呢?

FHIR资源的其他特征

  • 在资源之间所定义的链接关系始终采用的是单一方向,而系统则是利用索引能力来反向跟踪这些链接(因此说,特定的诊断报告资源DiagnosticReport将链接到特定的患者资源patient,而您就可以利用特定的索引,来获取特定患者的所有诊断报告)
  • 版本(Versions) – 实际上,如果还是采用上述的比喻,每个文件夹之中包含的就是一系列的页面,且每个页面分别代表一个不同的版本;这样,需要时,您就可以浏览查看那些既往版本
  • 扩展(Extensions) – 除了FHIR之中所定义的数据元,还可以对所有资源加以扩展,从而使其具有新的数据元。FHIR定义的仅仅是那些获得广泛采用的核心/常用/常见数据元。
  • 叙述(Narrative) – 每种资源里面都包括有一个该资源之中数据的富文本表达形式(rich text representation)。如果系统因为某种原因而无法理解特定的资源,那么,它在任何时候都可以向临床医生显示这部分的文本。

概貌/集成规范

FHIR资源的定义非常通用。在形形色色的不同系统之中,它们需要具有可用性——比如,在不同国家里,针对不同类型患者(儿科患者、老人病患者、甚至是兽医学服务对象)用于不同学科专业(心理学、肿瘤学、社会服务)的门诊和住院系统,以及个人电子健康档案、临床记录系统和二次利用系统。这些资源的设计依据的是大多数系统现在所能处理的内容。这些资源表单当中的大多数数据元都是可选的,因为至少在某些情况下,相应的数据并不都是已知的或者说相关的(合适的)。

这就意味着,这些标准数据元并不会始终都包含适合于特定情况的所有数据元。资源表单也不会去强制要求遵循那些可能适用于特定情况的规则。例如,某家医院可能对于本院儿科手术转诊介绍信(referral)的内容制定有若干的规则。其中,可能会要求提供诸如初级保健医师、父母姓名、儿童年龄和性别等等之类的信息。假如缺少其中任何一项信息的话,就会将其视为无效的转诊介绍信(对于该医院这种类型的转诊介绍信来说)。

在FHIR之中,这个问题是利用一种特殊类型的,称为“概貌(Profile,集成规范)”的资源来解决的。概貌制定的是关于那些标准资源的规则,其中表达的是诸如下列各项之类的内容:

  • 哪些是必备的数据元
  • 特定的系统究竟采用的是什么术语集代码
  • 究竟额外定义了什么样的扩展

在FHIR概貌之中,将会找到大多数关于究竟如何/应当如何表达特定事物的实际临床知识。在实验室领域,将会有若干的不同概貌,分别针对基础化学、微生物与培养、结构化组织学报告等等。在临床领域,对于胸痛的检查,可能会有若干的概貌用来描述标准的一套观察和评估结果。

目前,概貌方面正是FHIR仍有相当多编制开发工作要做的地方。

附录:数据类型概要

本附录旨在罗列所有的FHIR数据类型,并对其功用加以简要介绍:

Simple Data Types(简单数据类型): 低层次信息技术领域核心种类的数据类型

  • string(字符串型): 由文本字符所组成的序列
  • integer(整数型): 简单数字(无小数点)
  • decimal(小数型): 任何实数值
  • boolean(布尔型): True 或 false
  • base64Binary(Base64编码二进制型): 信息技术名词,表示计算机知道如何处理的一串字节。例如,图像、PDF文件、音频剪辑等等。
  • uri(URI型): 您可以输入到网页浏览器地址栏当中的一种通用资源定位符(URL),但也允许采用浏览器并不知道的其他种类
  • instant(时刻型,瞬间型): 日期 + 时间 + 时区——当系统知道确切时间时使用
  • date(日期型): 任意已知程度的日期
  • dateTime(日期时间型): 任意已知程度的日期/时间
  • code/oid/uuid/id(代码型、OID型、UUID型及ID型): 特殊种类的字符串,旨在利用受控取值来标识不同的事物

Complex Data Types(复杂数据类型): 各种资源当中的常见模式

  • Attachment(附件型): 文档、图像等——类似于电子邮件附件
  • Coding(编码型): 选自某部代码系统(如SNOMED CT、ICD-X等,或者是本地所编制的代码系统)的代码
  • CodeableConcept(可编码概念型): 一条或多条代码和/或文本。大多数情况下将采用这种数据类型,而不是编码型Coding,因为它所提供的灵活性更好
  • Quantity(数量型): 带有计量单位的某种数值。而且,此类取值还可以带有一个英文的大于号“>”或小于号“<”
  • Range(范围型): 数量范围,包括高值和低值,或者说上限和下限。
  • Ratio(比率型,比值型): 分子 : 分母(Numerator : Denominator)——适用于表示滴度和开单率(billing rates)
  • Period(时间段型,时段型,时期型): 起始日期/时间 -> 结束日期/时间
  • SampledData(采样数据型): 来自于特定装置或者说仪器设备的测量值序列
  • Identifier(标识符型):用于记录与当前事物相关联的标识符
  • HumanName(人员姓名型): 姓氏、名字、姓名类型、文本摘要(text summary)
  • Address(地址型): 通讯地址(国家、州别/省市自治区、邮政编码、街道地址等)+ 类型和摘要
  • Contact(联系方式型): 电话、电子邮件等联系方式
  • Schedule(日程型,时间表型,日程安排型):某件事情所要出现/发生的一套未来日期(事件列表,或者是一份重复性时间表)

原文链接

参阅(HL7CNWiki内部的相关页面)

外部链接