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文件时,这些规则并不适用。

了解更多EDI,请您电话 150-0298-3180 / 177-8250-8152 或邮件 edi@kasoftware.cn 联系我们,获取 30 天全功能 免费试用 版本EDI软件。

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

标签: , ,
文章分类 edi, edi 电子数据交换, share 知识分享