医疗系统的互操作性是数字医疗系统中的一个关键概念。它意味着不同的医疗系统、设备和应用程序能够轻松地交换并理解彼此的信息。这种能力对于提供高质量的患者服务、促进医生、护士、医院和实验室之间的有效沟通以及提升整体医疗数字基础设施的水平都至关重要。
什么是医疗互用性?简单来说,医疗互操作性指的是不同的医疗系统、设备和应用程序能够顺畅地交换和使用患者的信息。比如你去看不同的医生,每个医生都需要了解你的医疗历史、过敏情况和药物信息。互操作性确保了所有你的医疗服务提供者可以通过网络访问和分享这些重要的信息,无论他们用的是什么系统。
早些时候,在医疗行业,患者的病历和数据都是手写的,仅以纸质档案的形式保存。但现在,一切都数字化了,患者的医疗数据也不例外。所有的医院都使用了电子健康记录(EHR)系统,例如Epic 和 Cerner。现在,就像软件工程领域中的其他数字系统一样,每个EHR系统也可能有自己的标准和协议,其他系统的理解和兼容性可能较差。
兼容性重要性——实际例子举个假设的例子,让我们假设Epic可能会按如下方式存储患者数据:
{
"patient": {
"name": "John Cena",
"age": 41,
"condition": {
"病症描述": "左肺部感染",
"严重程度": "4",
"治疗方案": "14天的抗生素治疗",
"最后评估日期": "2024-10-08",
"症状": "患者出现发热和呼吸急促的症状。",
"风险因素": ["吸烟史", "糖尿病"],
"过敏": ["青霉素"]
},
"就诊日期": "2024-10-10"
}
}
cerner可能正在按照以下标准存储病人数据:
{
"patient": {
"name": "殡葬师",
"age": 48,
"condition": {
"description": "左肺感染严重,情况危急",
"prescription": "服用抗生素14天",
"lastEvaluationDate": "2024年10月08日",
"signs": "患者出现发热和呼吸急促的症状。",
"contributingFactors": ["吸烟", "患有糖尿病"],
"allergies": ["青霉素"]
},
"dateOfVisit": "2024年10月10日"
}
}
在这样一个例子中,当 Epic 将约翰的数据发送给 Cerner 时,由于双方遵循不同的标准,条件的“严重性”、“用药”、“病症”和“风险因素”可能会丢失,因为 Cerner 要么没有这些字段,要么即使有,也使用了不同的键名。
{
"patient": {
"name": "John Cena",
"age": 41,
"condition": {
"description": "左肺部感染",
"prescription": "无",
"lastEvaluationDate": "2024-10-08",
"signs": "症状",
"contributingFactors": "影响因素",
"allergies": ["过敏原:青霉素"]
},
"dateOfVisit": "就诊日期:2024-10-10"
}
}
这可能会导致丢失有关患者病情的关键信息,造成治疗延迟或对健康状况的误解。这可能导致错误的治疗,甚至危及生命安全。
医生能够理解这两种数据格式中的确切信息,但这里我们讨论的是系统之间的互操作性,而不是不同医院中医生之间的互操作性。软件系统不像人那样直观,它们需要数据以标准格式,以便处理和利用这些数据。
HL7 (健康Level 7, HL7)- HL7 代表 Health Level 7。
- 它是一套用于交换电子医疗信息的国际标准。其主要目标是确保医院、实验室、诊所等不同的医疗系统能够无缝共享患者的数字数据。
- 它由 HL7 国际组织 开发,该组织成立于1987年。
- HL7 标准侧重于应用层,即在 开放系统互连模型 中的“第七层”,因此名字中的 7 来自 HL7。
- HL7 的目标是通过建立一个通用的数据交换语言来增强已实现它的医疗信息系统 (HIS) 之间的互操作性。它专注于不同 HIS 之间的接口,以创建一个通用的数据交换语言,但并不规定系统架构或数据存储方式。
- 它是一种基于事务的协议,由诸如患者入院之类的事件驱动。
HL7 消息是一种可读的文本,这种文本被分解为有意义的片段,并以数据包的形式在应用程序之间传输,通过明确定义的通信协议,包含握手协议和确认程序。
和其他技术一样,HL7 也使用一些特定术语,我们将尝试通过一个例子来理解这些术语,避免枯燥的定义。
0. 假设我们有如下患者数据,如下所示(不是HL7格式,仅为便于阅读):
patientID: 123456789
patientName:
lastName: Lokhi
firstName: Virat
middleName: 无
title: 先生
dateOfBirth: 1990-01-01
gender: 男
address:
street: 420 主街
city: 孟买
state: 马哈拉施特拉
zipCode: 400001
phoneNumber: 111-222-3333
visit:
attendingDoctor:
id: 1234
name: 全科医生
referringDoctor:
id: 6789
name: 专科医生
admitDateTime: 2024-10-11T12:30:00
dischargeDateTime: 无
guarantor:
guarantorID: 987654321
guarantorName:
lastName: Lokhi
firstName: Anushke
middleName: 无
title: 女士
relationship: 妻子
dateOfBirth: 1992-05-15
gender: 女
address:
street: 420 主街
city: 孟买
state: 马哈拉施特拉
zipCode: 400001
phoneNumber: 222-111-3333
假设我们是开发HL7标准的人,我们想用标准格式来传输这些数据。那我们就从头开始构建这个HL7格式吧
- 由于发送方和接收方都遵守相同的规范,并且知道所有字段及其顺序,我们可以避免发送键,只需按正确顺序发送值即可。这样可以节省网络带宽。因此,我们已经将示例中的三个部分:患者详情、就诊和担保人分成了三个只包含值(不含键)的行/部分。在HL7消息中,每一行/部分被称为一个段,即Segment,或片段。
123456789,Lokhi,Virat,,先生,1990-01-01,男,420 Main Street Mumbai,Maharastra,400001,111-222-3333
1234,初级医疗,6789,专科,2024-10-11T12:30:00
987654321,Lokhi,Anushke,,女士,420 Main Street Mumbai,Maharastra,400001,222-111-3333,1990-01-01,女,配偶
2. 但是你可以看到一个问题,即分隔符/分界符(逗号)。我们可以在值本身中使用逗号,例如地址,因此不能用于字段分隔,否则会打乱字段顺序。现在,逗号(,)、破折号(-)、斜线(/)、冒号(:)、句点(.)等都是常用的标点符号,因此不能用作分隔符。所以,使用竖线(|)作为字段分隔符,用^表示子字段分隔 (比如,在姓名字段中,有名字、中间名、姓氏和头衔等子字段) :
123456789|||洛奇^维拉特^^先生||1990-01-01|男|||420 主要街道,孟买,马哈拉施特拉邦,400001||111-222-3333
1234^初级|6789^专科|||||||||||||||||||||||||||||||||||2024-10-11 12:30:00
987654321|洛奇^安舒克^^女士||420 主要街道,孟买,马哈拉施特拉邦,400001|222-111-3333||1992-05-15|女||妻子
- 竖线字符 (|) 作为字段分隔符。例如:12345678|Virat|1990–01–01
- 脱字符 (^) 作为子字段(组件)分隔符(^)。例如:123456789|Lokhi^Virat^Mr|1990–01–01
- 和号 (&) 作为子值(子组件)分隔符。例如:Virat 的头衔中有多个头衔:123456789|Lokhi^Virat^Mr &Dr|1990–01–01
- 波浪号 (~) 作为重复分隔符(多个值)。例如,Virat 有多个联系电话:123456789|Lokhi^Virat^^Mr|1990–01–01|M|420 Main Street^Mumbai^Maharastra^400001|111–222–3333~444–333–1111
3. 现在,我们的HL7消息不仅会有这三个段,还可能包含其他段,而其中一些段可能某些患者没有。例如,某位患者可能还会有两个额外的段,一个是检验申请,一个是检验结果,而Guarantor段有可能不存在。它可能看起来像这样:
123456789|||洛希^维拉特^^先生||1990-01-01|M|||420 Main Street^Mumbai^Maharastra^400001||111-222-3333
1234^初级保健|6789^专科||||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
123456^实验室|987654^医院|1234^全面血液检查^L|||202410111230|||1234^医生^拉什米||||||F|||202410111230
NM|1234-5^血红蛋白^LN|1|15.5|g/dL|13.0-17.0|N|||F
现在我们可以看到,这里担保人部分不可用,而新的部分,例如检验请求和结果已经出现。因此,很难知道每个部分的内容。我们需要在每个部分的开头添加标识符,以说明该部分包含的信息:
我们需要在每个部分的开头添加标识符,以告知该部分包含的信息:
PID|123456789|||维拉特^洛基^^先生||1990-01-01|M|||420 Main Street^孟买^马哈拉施特拉^400001||111-222-3333
PV1||||||1234^初级医疗|6789^专科||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
GT1|987654321|洛基^安舒克^^女士||420 Main Street^孟买^马哈拉施特拉^400001|222-111-3333||1992-05-15|F||配偶
OBR|123456^LAB|987654^医院|1234^血常规^L|||202410111230|||1234^医生^拉什米||||||F|||202410111230
OBX|NM|1234-5^血红蛋白^LN|1|15.5|g/dL|13.0-17.0|N|||F
-
PID : 患者标识
-
PV1 : 就诊信息
-
GT1 : 担保人
-
OBR : 观察申请
- OBX : 观察数据
4. 一个段可以包含多个条目。例如,同一个病人可能多次来医院就诊,做了多次检查等。因此,同一个段落内会有多个条目,所以我们需要为每个条目提供一个Id,在HL7消息中,我们称这个Id为SetId。它作为段标识符后的第一个字段出现:
PID|1|123456789|||洛希^维拉特||1990-01-01|M|||420 Main Street^孟买^马哈拉施特拉邦^400001||111-222-3333
PV1|1||||||1234^初级保健|6789^专科||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
GT1|1|987654321|安舒克^洛希^^女士||420 Main Street^孟买^马哈拉施特拉邦^400001|222-111-3333||1992-05-15|F||配偶
OBR|1|123456^实验室|987654^医院|1234^全血细胞计数^L|||2024-10-11T12:30:00|||1234^医生^拉什米||||||F|||2024-10-11T12:30:00
OBX|1|NM|1234-5^血红蛋白^LN|1|15.5|g/dL|13.0~17.0|N|||F
5. 现在,我们已经准备好需要共享的实际数据,但关于这条消息本身的细节呢,也就是 这条消息的元数据。我们知道,在网络通信中,当我们通过网络发送一个数据包时,这个数据包不仅包含要共享的实际内容,还包含关于数据包的元数据,如发送者、接收者、时间戳、数据包ID等。类似地,一个 HL7 消息同样包含一个元数据段,以 MSH 标识符开头:
MSH|^~\&|HOSPITAL|LAB|PATIENT|EHR|202410111230||ADT^A01|123456|P|2.5
PID|1|123456789|||Lokhi^Virat^^Mr||1990-01-01|M|||420 Main Street^Mumbai^Maharastra^400001||111-222-3333
PV1|1||||||1234^初级保健|6789^专科医生||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
GT1|1|987654321|Lokhi^Anushke^^Mrs||420 Main Street^Mumbai^Maharastra^400001|222-111-3333||1992-05-15|F||妻子
OBR|1|123456^LAB|987654^HOSPITAL|1234^全血细胞计数^L|||2024-10-11T12:30:00|||1234^Doctor^Rashmi||||||F|||2024-10-11T12:30:00
OBX|1|NM|1234-5^血红蛋白^LN|1|15.5|g/dL|13.0-17.0|N|||F
MSH 段提供了重要的元数据,包含发送方、接收方、消息类型以及其他重要标识符和时间戳的详细信息。这些信息对于正确处理消息、路由消息以及理解交换数据的背景至关重要。
- MSH:这是消息头段的标识符。
- 字段分隔符 (|):此字符用于分隔段内各个字段。
- 编码字符 ( ^~\&):这些字符定义了数据字段的编码方式。
- 发送应用 ( HOSPITAL):发送消息的应用程序或系统的名称。在此情况下,表示医院系统。
- 发送机构 ( LAB):发送消息的机构(例如,特定的部门或地点)。此处指实验室。
- 接收应用 ( PATIENT):预期接收消息的应用程序或系统的名称。这通常是患者的管理系统。
- 接收机构 ( EHR):将接收和处理消息的机构或系统,此处指电子健康记录 (EHR)。
- 消息的日期/时间 ( 202410111230):消息生成的时间戳,格式为 YYYYMMDDHHMM ,表示 2024 年 10 月 11 日 12:30。
- 消息类型 ( ADT^A01):此字段指明消息类型。ADT 代表入院、出院、转院,表示消息与患者入院或状态变化相关。A01 指明 ADT 类别中的事件类型(在此情况下,A01 表示患者入院。当患者被收治到医疗设施时使用)。
- 消息控制 ID ( 123456):此特定消息的独特标识符,有助于消息的追踪和关联。
- 处理 ID ( P):指示消息的处理模式。P 通常表示“生产”,表明消息正在实时生产环境中发送(其他值包括 T: 培训 和 D: 调试)。
- 版本 ID ( 2.5):表示消息遵循的 HL7 标准版本。在此情况下,版本为 2.5。
6. 最后,我们在HL7的定义中提到“这是一种基于交易的协议,由诸如患者入院之类的事件驱动”。那么,具体哪个部分描述了发生的事情及其相关信息呢?让我们添加事件段EVN:
MSH|^~\&|HOSPITAL|LAB|PATIENT|EHR|202410111230||ADT^A01|123456|P|2.5
EVN|A01|202410111230|202410111200|123456789|RSharma
PID|1|123456789|||Lokhi^Virat^^Mr||1990-01-01|M|||420 Main Street^Mumbai^Maharastra^400001||111-222-3333
PV1|1||||||1234^Primary Care|6789^Specialist||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
GT1|1|987654321|Lokhi^Anushke^^Mrs||420 Main Street^Mumbai^Maharastra^400001|222-111-3333||1992-05-15|F||WIFE
OBR|1|123456^LAB|987654^HOSPITAL|1234^Complete Blood Count^L|||202410111230|||1234^Doctor^Rashmi||||||F|||202410111230
OBX|1|NM|1234-5^Hemoglobin^LN|1|15.5|g/dL|13.0-17.0|N|||F
- 事件类型代码 ( A01) :表示事件的类型。在这里,A01 表示患者被收治入院。
- 记录日期/时间 ( 202410121230) :事件记录的日期和时间。这意味着患者于2024年10月11日12点30分入院。
- 计划事件日期/时间 ( 202410121200) :事件计划的日期和时间。这意味着患者计划于2024年10月11日12点入院。
- 事件原因代码 ( 123456789) :一个可选字段,包含表示事件原因的代码,例如,急诊、手术等。
- 操作员ID ( RSharma) :表示记录该入院记录的人或系统的ID。在本例中,表示用户RSharma记录了该入院记录。
所以,我们现在已经得到了最终的HL7消息,你可以使用任何HL7解析器来查看它。
MSH|^~\&|医院|检验科|病人|EHR|202410111230||ADT^A01|123456|P|2.5
EVN|A01|202410111230|202410111200|123456789|RSharma
PID|1|123456789|||Lokhi^Virat^^Mr||1990-01-01|M|||主街420号^孟买^马哈拉施特拉^400001||111-222-3333
PV1|1||||||123^初级保健|6789^专科医生||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
GT1|1|987654321|Lokhi^Anushke^^Mrs||主街420号^孟买^马哈拉施特拉^400001|222-111-3333||1992-05-15|F||妻子
OBR|1|123456^检验科|987654^医院|1234^血常规^L|||202410111230|||1234^门诊医生^Rashmi||||||F|||202410111230
OBX|1|NM|1234-5^血红蛋白^实验室名称|1|15.5|g/L|13.0-17.0|N|||未确认
HL7 版本信息
HL7有多个版本。其中,_2.x_版本是最广泛使用的。最新的版本是FHIR。
HL7 版本 2.x 版- 它在1989年发布。
- 当医疗卫生企业中发生事件时,会发送HL7 2.x 消息。例如,入院、出院或转院(简称 ADT)等事件。每当患者入院或出院时,处理事件的系统会向所有需要通知的系统发送一个 HL7 2.x 消息。这样的一条消息示例如下:
MSH|^~\&|HOSPITAL|LAB|PATIENT|EHR|202410111230||ADT^A01|123456|P|2.5
EVN|A01|202410111230|202410111200|123456789|RSharma
PID|1|123456789|||Lokhi^Virat^^先生||1990-01-01|M|||420 Main Street^Mumbai^Maharastra^400001||111-222-3333
PV1|1||||||1234^Primary Care|6789^Specialist||||||||||||||||||||||||||||||||||||2024-10-11T12:30:00
GT1|1|987654321|Lokhi^Anushke^^太太||420 Main Street^Mumbai^Maharastra^400001|222-111-3333||1992-05-15|F||WIFE
OBR|1|123456^LAB|987654^HOSPITAL|1234^完整血细胞计数^L|||202410111230|||1234^Doctor^Rashmi||||||F|||202410111230
OBX|1|NM|1234-5^血红蛋白^LN|1|15.5|g/dL|13.0-17.0|N|||F
- HL7 2.x 使用其自有的基于 TCP 的协议 MLLP 进行通信时使用。
- 它通过允许可选的自定义字段和额外的消息段来支持数据变化的支持。
- 所有 HL7 2.x 版本都支持向后兼容。
- 它于2005年发布。
- 它被开发为对原始HL7标准的全新定义,旨在更加一致、严谨和形式化。
- 它使用XML格式。
- 它基于一个名为RIM(参考信息模型)的概念框架。它定义了诸如患者、组织和观察等核心医疗实体为类,并建立了这些实体之间的关系。
- 因为它与版本_2.x_不兼容,所以并未被广泛接受。
- FHIR(发音为“fire”)代表 快速医疗信息互操作资源。
- 它于2015年发布。
- FHIR 基于“资源”这一概念构建,资源是一个独立的数据单元,代表特定的信息,比如患者、药品或预约。
- 它利用 REST(表述性状态传递)原则,允许开发者使用标准的网络协议与 FHIR 资源进行交互。应用可以通过 RESTful API 使用标准 HTTP 方法(如 GET、POST、PUT 和 DELETE)来与 FHIR 资源进行交互。
- 这意味着医疗应用程序可以轻松地通过互联网创建、读取、更新和删除(CRUD 操作)资源,就像与常规的网络服务进行交互一样。
- FHIR 具有足够的灵活性来支持各种用例,从简单的患者记录到复杂的临床信息。它还支持扩展,允许组织根据需要添加自定义字段或资源,而不影响标准框架。
- 它利用了现代网络技术,包括 JSON(JavaScript 对象表示法)和 XML(可扩展标记语言)。这使得开发人员可以更容易地将 FHIR 集成到现有应用程序中。
共同学习,写下你的评论
评论加载中...
作者其他优质文章