为什么HL7消息文本总是大写？

Question

为什么HL7 v2消息中的所有文本值都大写？例如，其中一个示例消息中的名称字段如下所示：

SANDIEGO^CARMEN^^^^

为什么不使用小写字母？如果所有字母都大写，则案例信息将丢失。似乎最初的情况会更好：

Sandiego^Carmen^^^^

这有什么技术原因吗？

Answer 1

出现这种情况有很多不同的原因。首先，HL7中的大写文本值不是必需的，您可以使用ALL CAPS或小写，任何一种方式都可以接受。

最终，它基于最初创建消息的任何系统。许多医疗应用程序将患者标识符信息保留为大写字母，以便它们不会被误认为是不同的字母或数字 - 例如1和l。此外，正在编写此信息的数据库可以使用相同的做法并自动将字母大写。在任何行业中，通常的做法是将重要的重要信息保存在所有上限中，因为这个原因 - 减少混淆，减少混淆。

如果它是旧系统，如AS / 400（“绿屏”），则通常的做法是将所有输入字段大写。

我们在我的工作场所使用的LIS不会大写，而我们的患者记录系统也可以。如果您在HL7消息中接收带有大写文本字段的消息，那么这是由于发送应用程序如何格式化该数据 - 但是并不需要在所有大写字母中进行格式化。

Answer 2

我同意@ cloyd800的回答，并补充说HL7 2.x和HL7 3.x允许任何字符，包括大写和小写，甚至是重音字符，如“Nováček^František”。

有关HL7 2.x中允许的字符集的一些讨论，请参阅http://www.healthintersections.com.au/?p=350

有关精确定义，请参阅相应的HL7规范，与MSH-18

关联的表格

我也不知道集成医疗保健企业（IHE）方面的任何限制（参见例如http://wiki.ihe.net/index.php?title=Patient_Information_Reconciliation以获得更多可能相关集成配置文件的链接）其他比

  

当有多个系统进行通信时，允许的约束集（例如字段长度）必须是所有各方都能理解的子集（来自IHE技术框架的简化和重新引用的引用）

我从我们的软件与之通信的系统中实际观察到的原因：

1. 某些第三方遗留系统不支持其他ASCII字符集编码（例如，数据库后端中的列不支持UTF8或Unicode）
2. 某些第三方通信经纪人将消息从一个系统转移到另一个系统时，输入/中间/输出字符集的正确转换存在问题（例如，在传输转换为纯文本文件和使用某些纯文本文件命令行处理脚本期间） ）
3. 某些遗留系统使用患者姓名作为唯一标识符（无数字识别码，例如没有患者的医疗保险ID）
4. 某些系统使用大写的姓氏和普通的套用名字来确保数据中没有输入错误，因为全名编写约定可能不同。例如在捷克语中，首先写出名字是自然的，但有时候更实际（例如用于排序）要先写下姓氏。大写的姓氏有助于检测哪个特别是当它是一个不常见的外包名称时，以及原始数据来自只有1个输入字段的遗留系统的全名。

因此规范并未说明您不能使用任何套管名称。但它表示您的系统必须与其他系统兼容。

适用于您的系统的哪些约束取决于其环境。在我们的软件中，我们几乎没有向后兼容的开关，例如我们可以将其配置为将患者姓名发送到HL7网关XY，并删除重音字符，并将所有上部字符组合。但是只有在我们连接某些遗留系统时才会启用它，它不是默认的