工程

您想知道的有关HL7和Redox中字符编码的所有信息

2017年11月15日发布
尼克·哈特(Nick Hatt)

字符编码是技术人员有史以来最不可思议的主题之一,但实际上它支撑了我们在计算机上看到的每一段文字。本文将重点介绍HL7v2和Redox API,以及它们如何处理不同的编码。

首先,在阅读本文之前,您应该具有基本的编码背景。我建议 Kunstube的这篇文章 作为全面的介绍。如果您对ASCII与UTF-8的不同感到满意,请继续阅读。

氧化还原API始终使用UTF-8

如果您阅读介绍性文章,那么应该清楚为什么UTF-8接管了Web的事实上的标准-它’节省空间,并且可以表示整个unicode字符空间。

同样,当您收到我们的邮件时,将使用UTF-8对其进行编码。

如果您将我爱你❤️发送到API,它将以这种方式显示在Redox仪表板中。如果您尝试将其发送到EHR,可能会开始发生奇怪的事情。

许多产品不能很好地处理Unicode

在构思Unicode之前,已经建立了许多EHR供应商(并开发了许多代码库),但支持程度却差得多。如果您还记得尝试让网页在90年代后期显示’通过切换编码,当时的许多软件都支持 字符集。如果你’ve ever heard of Windows 1252,’从ASCII顶部的额外位获得的额外128个字符。

如果您迫切需要将unicode放入EHR,请确保首先与Redox安装团队联系。在某些情况下,仅某些字段(如名称)将支持unicode,并且我们实际更新它的方式可能会有所不同,具体取决于他们对HL7规范的了解程度。

HL7v2对Unicode的支持本身就是一门完整的科学

HL7v2中除ASCII之外如何进行编码的大多数细节在HL7v2规范的第2章中.

该过程如下所示:

  1. 默认值为7位ASCII
  2. 分隔符必须为7位ASCII(包括回车符)
  3. 如果填充了MSH-18,则第一个重复表示邮件的默认编码
  4. 如果第一次重复为空,则默认值为7位ASCII
  5. 附加重复指示消息中可能使用的其他编码方案

因此,执行UTF-8就像输入“UNICODE UTF-8” in MSH-18, right?

并非完全如此-与大多数HL7v2实现一样,这通常是大多数实现者的疏忽。

使事情复杂化的是,使用转义序列可以容纳那些多种不同的编码以及可以随字段变化编码的EHR。因此,您可以在一个字段中混合使用Unicode,IR87等,解析器应该能够处理它。

氧化还原如何处理这个

我们的HL7解析器是一项非常漂亮的技术。我们将所有消息解析为JSON。由于我们可以执行此步骤而不必担心编码,因此,如果需要,我们可以将每个字段的实际处理往下推,并如上所述按每个字段应用单独的转换。

在实践中,我们’在很多情况下,发送的内容不是7位ASCII。但是,在极少数情况下,少数几个小符号可能会造成严重破坏。度数符号°和指数符号(如²和³)在以单位显示时有一个讨厌的习惯。例如,度数符号表示为 B0 (176) in Windows-1252和 F8 (248) in 第437页

Interestingly enough, the Unicode code point for ° is 2 bytes (00B0). In UTF-8, that’s C2B0,因此,如果您将消息解释为Windows-1252,则您’d get À° 在437中,以及在UTF-8中正确的°符号。相反,如果消息在Windows-1252中,则很可能会出现某种错误,因为 B0 本身不是有效的UTF-8序列。 kes。

设计应用程序的建议

在这一点上,您可以开始了解如何知道应该发送什么符号,如何使用 程序员’s calculator.

但是,向后工作是很多工作,因此,如果您’重新设计与Redox集成的应用程序时,请牢记这些。

  1. 与Redox API通话时能够发送/接收UTF-8
  2. 确保应用程序的全部内容(数据库,外部服务等)可以处理该UTF-8
  3. 用你的眼球。如上所述,如果发送HL7的用户未遵循规则,则可能无法发现错误的编码。

We’重新保持我们的眼球去皮。祝你好运,慢走。