SNIP验证EDI文件

SNIP验证指的是一系列可应用于EDI文件的约束条件，以确保EDI数据符合HIPAA标准。因此，SNIP验证支持是选择EDI处理解决方案时需要考虑的一个重要因素。想要了解SNIP验证，首先要了解EDI规范本身。因此，本文主要包括EDI规格概述以及关于SNIP验证级别的说明。

本文旨在为任何实施 EDI 解决方案的人提供帮助，而不仅仅是使用知行EDI系统的人。

EDI规范

EDI规范是用于创建业务文档的准则，不同的公司可以通过这些EDI规范建立共同的数据语言和理解。EDI解决方案可以严格或宽松地执行管理这些文件的准则。较为宽松的执行方式可能会避免抛出不必要的错误，而较为严格的执行方式可能会防止出现进一步的数据处理问题。

因此，仅凭EDI规范不能决定EDI处理方案应该认为什么是有效或无效的EDI数据。下一节介绍的SNIP验证级别，增加了EDI规范应该如何执行的明确规则，以及额外的执行规则（在更高的验证级别）。

为了更快的了解EDI规范，将不同的规范划分为三层结构是很有用的。

EDI标准
版本
文件类型

EDI标准

首先，在层次结构的顶层，EDI有几个不同的标准，包括：

X12（即ANSI X12）
EDIFACT
TRADACOMS

这些标准都是为了达到同样的目的，即确保双方就如何解释业务数据达成一致，但并不具有互操作性。例如，遵守X12标准的文档就不能成为有效的EDIFACT文档。

版本

每个EDI标准都有多个版本的标准。偶尔会发布新的版本，对标准所定义的规则进行更新。EDI交换中的各方必须就要使用的EDI标准（如X12）和该标准中的版本达成一致。

新版本中发布的更新通常是增量更新，因此每个标准的核心要素在每个版本中都保持不变。即使两个X12文档使用标准的不同版本，但两个X12文档之间看起来仍然十分相似。因此，对于使用不同版本的一方来说，EDI数据的某些方面可能是无法理解的。

X12版本的常见示例包括：

00401
00403
00501

EDIFACT版本的常见示例包括：

D96A
D96B
D97A
D97B

文件类型

每个标准的各个版本都定义了一套文件类型。每种文件类型都是根据特定的业务交换而设计的；例如，管理采购订单文件的规则与管理医疗保健登记索赔文件的规则不同。

每种文件类型都通过一个单独的模式文件来定义。该模式文件包含关于单个EDI段/元素的预期数量和顺序的信息。除了特定文件的模式外，每个版本都有一个通用模式文件，其中包含了适用于所有文件类型的段/元素信息（例如，某些元素的可能值集等）。

因此，要建立EDI交易关系，双方必须就EDI标准、该标准中的版本以及与其数据交换有关的具体文件类型(模式)达成一致。

SNIP验证

SNIP验证描述了七个级别的数据验证，它们与上一节中提到的模式相关，但又是分开的。每个级别或“类型”都会增加文档数据约束的严格程度。这些类型是累积性的，这意味着执行SNIP验证类型4也需要执行类型3、2和1中的规则。

将SNIP验证添加到EDI处理解决方案中，有助于明确EDI文档必须遵守EDI标准中定义的模式的紧密程度。此外，更高级别的SNIP验证可以确保EDI文档中包含的数据在敏感或受监管的环境中有效，例如符合HIPAA标准的EDI解决方案。本节包含按SNIP验证类型建立的约束条件的摘要。

SNIP类型1

SNIP类型1验证EDI数据的基本语法完整性。这包括要求在文档中只出现有效的EDI段，并按照EDI模式中定义的顺序出现。

仅仅是类型1并没有在EDI文档模式已经施加的约束条件之外引入额外的约束条件，强制执行这些约束条件是成功解析EDI数据的必要条件。因此，任何EDI处理解决方案都应默认支持SNIP类型1。

SNIP类型2

SNIP类型2验证EDI段、元素和限定符在文档中出现的次数。这包括确保所需的段/元素存在，以及重复段在允许范围内的重复次数。

类型2和类型1一样，执行EDI文档模式中定义的规则，但这些规则不一定是解析EDI数据的组成部分。因此，一个宽松的EDI处理解决方案可能不会默认执行类型2验证。

SNIP类型3

SNIP类型3验证每个索赔行项目的总和是否等于总索赔金额。类型3是SNIP验证从简单地根据EDI文件模式验证EDI段的结构发展到验证这些段中的数据内容。确保报销总额的正确性有助于防止出现有问题的财务差异。

类型3不太可能被EDI处理解决方案所支持，因为这些解决方案没有专门的SNIP验证用以处理受HIPAA约束的EDI文档。

SNIP类型4

SNIP类型4验证段间值关系：如果元素A的值为 “X”，那么元素B的值必须为 “Y “或 “Z”。类型4验证确保EDI文档中的数据不仅对EDI模式有效，而且对同一文档中的其他值也有效。

类型4和类型3一样，需要特定于医疗保健的数据验证，一般EDI处理解决方案不可能支持这种验证。此外，类型4验证中涉及的特定代码和if-then关系可能因文档和实施而不同。

SNIP类型5

SNIP类型5对HIPAA接受范围内的特定代码集进行验证。一些EDI字段包含一个代码值，并且在HIPAA标准下只有特定的代码集有效。SNIP类型5确保代码字段包含这些标准认可的代码。

HIPAA标准定义了一组可接受的代码的例子包括：

NDC（国家药品代码）代码
ICD(国际疾病和相关健康问题统计分类)代码
CPT（现行程序术语）代码

类型5验证需要将EDI数据与外部资源进行交叉引用，因此实施时需要了解这些外部资源，并进行额外的配置以将这些资源提供给EDI处理解决方案。

SNIP类型6

SNIP类型6验证了在创建索赔数据记录时考虑到了保健服务的差异。例如，如果EDI文件涉及脊柱按摩服务，而不是精神病服务，EDI段（记录）可能有不同的要求。类型6验证确保EDI数据的结构与EDI文件的服务相匹配。

SNIP类型6验证涉及更具体的数据值验证，可能需要额外的工作来实现EDI处理解决方案中的这些验证规则。

SNIP类型7

SNIP类型7验证了某些EDI贸易伙伴的特殊要求。

医疗保险
医疗补助
印度卫生

实施规范中为这些特定的贸易伙伴提供了SNIP第7类规则，在与私营保险公司等其他伙伴交换EDI文件时，这些规则并不适用。

注：文案部分内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。