本指南适用于HL7中国的FHIR Connectathon测试。
Track 001 - 基础模块
主题介绍
FHIR是一个模型驱动的标准,它定义了丰富的医疗服务场景下的数据资源以及这些资源之间的关系,在所有的这些资源中,Patient(患者)、Encounter(就诊)、Organization(卫生服务机构)、Practitioner(卫生服务人员)、Condition(问题与诊断)和Observation(临床指标)会在很多的临床资源中被引用,我们把这些资源定义为基础资源。HL7 中国FHIR Connectathon测试的所有参与者必须首先测试通过该基础资源服务,才能开启其他测试场景的测试。
目标
为FHIR规范在中国卫生健康领域落地实施提供基线资源和交互约束。
测试系统是否支持FHIR基础实施指南声明的功能,包括医疗健康主数据的管理维护以及最基础的就诊流程:
- 测试系统患者管理的能力
- 测试系统卫生服务机构管理的能力
- 测试系统卫生服务人员管理的能力
- 测试系统处理不同就诊活动的能力
- 测试系统处理问题与诊断的能力
- 测试系统处理观察结果的能力
参与者
任何对FHIR规范在中国卫生健康领域落地实施感兴趣的人。
先决条件
- 已通读FHIR基础实施指南
- 了解 FHIR 的工作原理
- 一个正常运行的开发环境,其代码实现下面列出的所有角色,参与所有测试场景。
相关主题
本主题不依赖其它主题,并且设计为其它主题的依赖。
实施指南
FHIR基础实施指南
系统角色
可以将FHIR基础实施指南中规定的两种角色等价于医院内的两种系统角色:
医院信息系统(HIS)
等价于服务请求者,作为客户端,向EMR发起服务请求,获取患者相关数据。
电子病历信息平台(EMR)
等价于服务提供者。作为服务端,为医院内部诸如医院信息系统等提供数据服务,
Profiles
本规范中涉及到的Profile:
场景
包含两个就诊活动场景,一个是门诊,一个是住院。
患者刘康,男,2003年1月12日出生,民族汉,身份证号110101200301120019,社保卡号100000000000,家住北京市东城区景山前街4号,邮编100010,联系电话13800138000。联系人刘康的父亲刘勇,电话13012345678。
2024年3月18日上午10点,患者刘康,在北大人民医院骨科门诊进行就诊,主诉右膝盖无力,行走不变三个月,医生又记录了患者的血压和体重信息。最后经诊断为膝关节退行性病变,决定转到住院部进行住院手术治疗。
刘康于当天办理入院手续,分配的床位为外科楼3病区2病房1床,他的主治医生是李四医生,入院诊断是髋关节退行性病变,入院原因是髋关节置换术,经过8天治疗,刘康在4月26日成功办理出院。
期间,患者刘康更新了联系人的联系方式,手机号更换为13987654321。(用于患者更新)
场景1: 患者管理
场景2: 组织管理
场景3: 医师管理
场景4: 门诊活动
场景5: 住院活动
测试流程
本主题测评按如下步骤进行:
- 患者管理
- 组织管理
- 医师管理
- 门诊活动
- 住院活动
患者管理
- 患者注册
- 测试动作:客户端创建一个患者并调用create服务接口,将患者资源存储在服务器上。服务器分配患者资源id,meta.versionId及meta.lastUpdated 。
- 前置条件:测试前,该患者未在服务器注册
- 验证标准:患者在服务器上创建成功且正确,服务器端返回http status code 201, 返回的http头中必须包含Location用来指定新创建的患者资源地址,返回的http头中必须包含ETag来描述该资源的版本信息。服务器端还需要对收到的资源进行Profile校验。客户端需要保存服务器端返回的各种信息,比如id等,以用于后续的更新,读取,取消等
- 患者更新
- 测试动作:客户端更新场景#1创建的患者的信息并提交到服务器。患者资源利用患者ID获取。
- 前置条件:测试前,该患者已经在服务器创建。
- 验证标准:患者在服务器上成功更新,服务器端需要根据Profile进行校验
- 获取患者历史版本
- 测试动作:客户端向服务器提交检索,获取一位患者的历史信息。
- 前置条件:测试前,该患者资源至少做过一次更新。
- 验证标准:能够正确检索到该患者的历史信息(可通过浏览器查看患者信息)
- 患者查询
- 通过name、identifier、address、birthdate四个查询参数检索患者
- 测试动作:客户端向通过患者的name、identifier、address、birthdate在服务器进行检索
- 前置条件:测试前,该患者在服务器注册过。
- 验证标准:能够正确检索到所有该姓名的患者资源(可通过浏览器查看患者信息)
- 删除患者
- 测试动作:客户端通过一个患者资源ID在服务器上删除对应的患者资源。
- 前置条件:测试前,该ID对应的患者在服务器注册过。
- 验证标准:执行该删除操作后,通过姓名或该ID查询该患者均失败。
组织管理
- 新建A医院和骨科
- 测试动作:客户端新增一个A医院信息,调用服务器接口,服务器返回A医院信息资源id给客户方
- 前置条件:测试前,该就诊信息未在服务器注册
- 验证标准:就诊信息资源在服务器创建成功(可通过接口查询浏览内容)
- 更新A医院信息和骨科
- 测试动作:修改上一场景新建的A医院信息内容,调用服务器接口更新A医院信息内容
- 前置条件:测试前,该A医院信息已经在服务器注册
- 验证标准:A医院信息内容在服务器更新成功(可通过接口查询浏览内容)
- 获取A医院和骨科历史版本
- 测试动作:客户端向服务器提交检索,获取A医院信息的历史信息。
- 前置条件:测试前,该A医院信息至少做过一次更新。
- 验证标准:能够正确检索到该A医院信息的历史信息
- 通过查询参数”name”查询A医院和骨科
- 测试动作:通过参数,调用服务器接口查询A医院和骨科信息内容
- 前置条件:测试前,该A医院和骨科信息已经在服务器注册
- 验证标准:正确返回A医院和骨科信息内容
- 通过”partof”查询参数查询A医院下的所有科室
- 测试动作:通过A医院查询其下的所有科室
- 前置条件:测试前,该A医院和骨科信息已经在服务器注册
- 验证标准:正确返回A医院和骨科信息内容
- 删除A医院和骨科信息
- 测试动作:调用服务器接口删除就诊信息内容
- 前置条件:测试前,该就诊信息已经在服务器注册
- 验证标准:就诊信息内容在服务器删除成功(可通过接口查询确认删除成功)
医师管理
新曾、修改、历史、读取、读取历史
查询:通过查询参数’name’进行查询,可以通过name=’李’,name=’四’,name=’李四’查询到李四这个医生的资源
门诊活动
条件:就诊信息(Encounter)已生成,提供JSON或XML格式。
动作:支持针对该就诊信息的注册、查询、更新、删除、查看历史操作,通过POSTMAN等工具验证;
- 新建就诊信息
- 测试动作:客户端新增一个就诊信息,调用服务器接口,服务器返回就诊信息资源ID给客户方
- 前置条件:测试前,该就诊信息未在服务器注册
- 验证标准:就诊信息资源在服务器创建成功(可通过接口查询浏览内容)
- 更新就诊信息
- 测试动作:修改上一场景新建的就诊信息内容,调用服务器接口更新就诊信息内容
- 前置条件:测试前,该就诊信息已经在服务器注册
- 验证标准:就诊信息内容在服务器更新成功(可通过接口查询浏览内容)
- 获取就诊信息历史版本
- 测试动作:客户端向服务器提交检索,获取就诊信息的历史信息。
- 前置条件:测试前,该就诊信息至少做过一次更新。
- 验证标准:能够正确检索到该就诊信息的历史信息(可通过浏览器查看就诊信息)
-
通过查询参数”patient”或”subject”进行查询,该查询参数的类型为Reference,需要支持下列查询接口:
- 测试动作:通过参数,调用服务器接口查询就诊信息内容
- 前置条件:测试前,该就诊信息已经在服务器注册
- 验证标准:正确返回就诊信息内容
- 删除就诊信息
- 测试动作:调用服务器接口删除就诊信息内容
- 前置条件:测试前,该就诊信息已经在服务器注册
- 验证标准:就诊信息内容在服务器删除成功(可通过接口查询确认删除成功)
住院活动
住院和门诊流程一样。
问题与生命体征
与门诊流程同步进行。在门诊信息中添加主诉部分,记录了一些生命体征信息(Observation)和问题(Condition)。在展示门诊信息时,能同步展示生命体征信息。
最少需支持:
- 新增、读取
- 查询:最少应支持通过查询参数’encounter’进行查询。
验证规则
安全和隐私注意事项
在测评环境中没有对OAuth
或TLS
的要求(尽管在生产环境中需要此类技术)。