Algorithm 医学数据实时压缩算法

我正在寻找一种健壮、高效的数据压缩算法，可以用来提供医疗数据的实时传输（主要是波形-心率等）

如有任何科学论文的建议/链接，我将不胜感激

编辑：系统将基于服务器（最有可能安装在医疗点基础设施内）和移动设备（iOS和Android智能手机以及带有本机应用程序的平板电脑），波形将传输到这些设备。服务器将从医院收集所有数据（主要是波形数据）。在我的例子中，稳定性和速度比延迟更重要

---

这是目前我能提供的最详细的规格。我将调查您的建议，然后测试几种算法。但我正在寻找在类似体系结构中成功实现的东西。我也愿意接受关于服务器计算能力或服务器软件的任何建议。

不要将其视为实时数据或医疗数据-将其视为需要压缩以进行传输的数据包（最有可能是TCP数据包）。内容的细节只取决于压缩算法的选择，即使如此，也不取决于它是否是医学的，而取决于数据的格式/存储方式以及实际数据的外观。重要的是数据本身和整个系统的限制（例如，它是数据收集，如Holter监护仪，还是实时状态报告，如ICU中的心脏监护仪？接收数据的是哪种系统？）

查看数据，它是以原始二进制数据的形式呈现以供传输，还是以（例如）结构化XML或HL7的形式从另一个组件或设备接收（以文本表示数值）？压缩原始数据是最有效的选择，还是应该将其转换为只覆盖实际数据范围的专有二进制格式（2、3或4字节是否足以覆盖值范围？）？通过转换可以实现什么样的节约，以及兼容性问题是什么（例如HL7兼容性的丧失）

选择绝对最好的压缩算法可能也不值得做太多额外的工作，除非您将处于极低带宽的情况下；如果数据来自嵌入式设备，您应该平衡压缩效率与嵌入式处理器、工具集和周围系统的功能和限制。如果定制的压缩例程比工具中已经内置的东西节省5%，那么在嵌入式闪存中额外的编码和调试时间以及存储空间是否值得？现有的经过验证的软件库可以产生“足够好”的输出，尤其是医疗设备

最后，根据环境的不同，您可能希望牺牲一大块压缩来支持某种程度的冗余，例如传输数据的滑动窗口，这样任何X数据包的丢失都不会导致数据丢失。这可能会让您更改协议，也可能会更改设备的配置方式-流式UDP（无丢失数据包的重新传输）和TCP（发送方可能需要能够重新传输）之间的差异可能很大

而且，现在我已经谈论了系统方面，有很多关于分组和流式模拟数据的信息，从流式协议的开发，如GSM/CDMA和VOIP语音分组的细节。不过，对您的决策来说，最重要的驱动因素可能最终是设备和服务器端提供给您的工具集。使用现有的工具集，即使它们不是最有效的选择，也可以显著缩短开发（和上市时间），还可以简化医疗设备/产品的认证。在业务方面，花费额外的3-6个月的软件开发、寻找真正合格的开发人员以及处理监管部门的批准可能是最重要的因素

更新2012/02/01：我刚刚花了几分钟查看了12导联心脏负荷心电图的XML输出，总观察时间为12分钟以上，XML文件大小约为6MB。我估计，在研究标题中，超过25%的文件是重复的、可压缩的XML，波形数据是以逗号分隔的数字，范围在-200到200之间，集中在范围的中心，变化缓慢，数字穿过y轴，并在这一侧停留一段时间。假设您需要的大部分是波形值，在本例中，您将看到一个数据速率，没有4500KB/763秒的压缩或大约59kbps的压缩。完全未压缩并使用文本格式，您可以通过“2.5G”GPRS连接轻松运行该功能。在任何现代无线基础设施上，所使用的带宽几乎都是不可见的

我仍然认为股票压缩库会把这类数据当作午餐（可能会遇到压缩头和数据包头的问题）。如果您坚持要进行自定义压缩，我会考虑发送差值，而不是原始数字（除非您的原始数据已经存在偏移量）。如果您的数据看起来与我正在查看的数据类似，您可能会将每个项转换为-127到+127的1字节值，可能会将最末端保留为用于溢出的“特殊”值（根据您认为合适的方式处理这些值-特殊表示、错误等）。如果您希望传输效率稍低，处理速度稍快，则可以将每个值作为有符号的2字节值发送，这仍然比文本表示占用更少的带宽，因为当前每个值