Anthony,
There are several different issues here, some explicit, some implicit, so let
me throw in my $.02 in case it helps. If nothing else, I am sure more debate
will result.
Concept #1
The SNIP "Type 1" testing includes
X12 syntax as well as "compliance with X12
rules". For example, compliance with X12 semantic rules. And with X12
design rules.
So, even though from a strict syntactical perspective the qualifier in REF01
is a separate data element than the data element in REF02, and each one has a
min/max and a
data type (ID or AN), the rule is that the REF01 qualifier
qualifies the associated REF02 element, changing its (semantic) meaning.
Because this is a fundamental X12 principle, when a data element is
"qualified" the meaning of that data element has changed. So, if an AN data
element is qualified as being a date in D8 format (or RD8, or whatever) then
that AN data element has acquired a semantic meaning that restricts what can
be put in it. To put a date like "12/06/03" in an element that has been
qualified as D8 is incorrect, even if the length is still 8 bytes, because
the D8 qualifier changed the AN 1/35 into an element that can only contain 8
bytes of a date as yyyymmdd.
This principle of qualifying a data element and restricting its semantic
definition is a fundamental principle in X12. Without this principle the X12
transactions could not be used.
Technically speaking this is perhaps not an X12 "syntax" issue, but since it
is an X12 issue, it falls into "Type 1" instead of any of the other "Types".
Concept #2
To what extent should an EDI analyzer check the content of the EDI
transaction? There are different products in the market, doing a more or
less rigorous interpretation and validation of the X12 or HIPAA data. The
answer to this question depends on the intended use. More on this under
Concept #3 below.
You may be interested in only syntax checking of the kind that can be reported
with a 997. Or you may check for external code sets in addition to syntax.
Or check for semantic rules. Or check for additional business rules like
those expressed in the HIPAA IGs. Or check for trading partner specific
rules, or balancing, etc. This is why the SNIP
white paper tries to classify
the different types of testing.
Obviously there are products for every taste. Some of the common translators
only check for syntax issues that could cause the translator to fail, such as
missing trigger
segments at the beginning of the loops, or misplaced segments
in the transaction set. Some translators have other sets of rules for
checking the data, and some provide a HIPAA "toolkit" with additional
validation rules. The market demand has driven a variety of solutions, with
a varying degree of flexibility and completeness. Which one is right? The
one that suits your specific needs.
And, since you mentioned Claredi, the "Claredi Classic" service provides a set
of "compliance" or "validation"
tools whose
job is to check these
transactions to the maximum extent possible. The reasoning is that when you
are testing a transaction with one of these tools you ought to know about
every possible problem in the data stream. It really does not matter as much
whether the problem is an X12 syntax problem that can be reported with a TA1
or a 997, or the problem is a semantic issue, or an X12 principle, or an
external code set, or an implementation issue, or a trading partner specific
requirement. If it is a problem that could cause the transaction to fail at
some point, the tool ought to alert you about it. Which brings me to the
third concept.
Concept #3
What are you to do when you find a problem in the data stream? It depends.
Your reaction as the creator of the data stream may be (should be) different
than the reaction of the receiver of the data stream. The creator of the
data stream should make reasonable attempts to produce a data stream as clean
as possible, and the receiver of the data stream should make reasonable
attempts to accept even an imperfect data stream when necessary. Note the use
of the wiggle words "clean", "necessary", "reasonable", "imperfect", etc.
A typical example is whether the ICD9 should be sent with a period in it or
without the period. The receiver may be able to accept it either way and
handle the period in the translator according to its own needs.
There are several schools of thought on this. One says that the receiver will
try to accept every transaction that it reasonably can, rejecting practically
nothing. The other says that the receiver will try to reject every
transaction that it can. There are business reasons for both positions. And
there are a number of intermediate positions as well. It all depends on what
you want to accomplish.
So, if you are sending a date like 19999999, which is clearly an invalid date,
the result could be different based on the receiver's need for that specific
date. If the date is the date of service in a claim or encounter, the
receiver would be correct in rejecting the claim because the date of service
is essential to the business purpose. But if the offending date is the DOB
of the subscriber, the receiver may choose to ignore the date and the error
since the payer already knows the subscriber's DOB from the enrollment. Or,
the receiver may reject the offending DOB, because it is an invalid date.
Both options can be reasoned based on business needs.
This is the sort of decision that should NEVER be left in the hands of a
validation tool without "supervision" by the the owner. These decisions
should be based on business needs rather than on technicalities. The job of
a good compliance or validation tool is to detect as many potential errors or
problems. The user of this tool can them make an informed decision on what
to do and which of those problems are relevant or irrelevant. And these
decisions should be flexible enough to accommodate the variety of business
needs of the receiver.
One of the reasons why we are getting into this sort of debates is because
some people have bought a canned package that makes all these decisions for
them, and now they don't like how the decisions are made. The point is not
whether 19999999 is a valid date or not. It is clearly not a valid date.
The point is not whether the tool should detect invalid dates or not. In
most cases these sort of errors should be detected and reported. The point
is what to do once the error has been encountered.
<adv>
Claredi has put together a very flexible system, Faciledi, that incorporates
the best HIPAA transaction validation system, and includes thousands of
trading partner specific edits from over 200 "companion documents" that cover
about 1,000 payers. Once the transactions are validated against these
thousands of rules, the Faciledi customer can define which rules are
significant and which ones are irrelevant, which should produce an "error" or
some sort of message. Which cause the transaction to reject and which do
not. And, best of all, all this happens at the "business unit" level, so an
individual claim can be treated different from other individual claims in the
same transaction set. The result is the possibility to have a totally
flexible HIPAA transaction compliance validation testing every single claim
in the production stream, accepting them, rejecting them, and "routing" them
according to the owner's needs. It has many other benefits, such as the
production of 997, 999, 824, 277ack, and other reports. And it is an open
environment that integrates with any application or translator.
</adv>
So going back to your original question... should a validator validate dates?
By now you know that my answer is that it should. Including leap year rules.
But I suspect that is not the issue. I suspect that the issue is: should a
claim be rejected because there are certain aspects of the data stream over
which the sender or receiver don't agree with a particular vendor's
interpretation? And my answer tho that is that the customer is always right
and the vendor's interpretation should NOT force the customer into business
rules that are uncomfortable.
If you want, I can send you some other of my "musings" on related topics, such
as the one on "filters, screens and grates". Or, if you want to talk about
Faciledi, or talk with some of the customers that have installed Faciledi,
let me know.
Kepa Zubeldia
Claredi
On Friday 05 December 2003 05:54 pm, Mike Rawlins wrote:
> The bottom line on the interpretation was that the relationship between
> DTP01 and DTP02 (similar to the DMG case cited) was specified in a semantic
> note and not a syntax note. The 997 only reports on syntax errors, so it
> should only report if DTP02 failed the AN 1-35 criteria.
>
> Additional background that did not get included in the official response
> had to do with the lack of sufficient specificity in the standard to do the
> type of validation you suggest. For example, to validate the several date
> format specifications from a syntax perspective, the grammar and allowable
> patterns for the dates would have to be rigorously specified (probably in
> BNF or a regular expression). That type of specificity is not present in
> the standard.
>
> The response to the request for interpretation stated X12's
> position. However, there's nothing to prevent the WEDI SNIP White Paper
> (or those maintaining the HIPAA guidelines) from saying that the
> circumstance cited should force a "Type 1" error. However, if they do, I
> suggest they might want to supply the pieces I that I noted are missing
> from the X12 standard.
>
> Regards,
>
> Mike
>
> At 04:54 PM 12/5/2003 -0600, Rachel Foerster wrote:
> >Mike, I'm assuming that by now you've read my response on this topic. While
> >I agree that there is a semantic note providing a specific business meaning
> >to DMG02, I believe there is sufficient specifity with the X12 standard
such
> >that an syntax analzyer can apply reasonableness edits at a minute. So,
even
> >though I'm no longer an official member of X12C, I respectfully disagree
> >with C's interpretation on this query.
> >
> >The WEDI SNIP White Paper on Testing defines a Type 1 test as follows:
> >
> >Type 1: EDI syntax integrity testing - Testing of the EDI file for valid
> >segments, segment order, element attributes, testing for numeric values in
> >numeric data elements, validation of X12 or NCPDP syntax, and compliance
> >with X12 and NCPDP rules. This will validate the basic syntactical
integrity
> >of the EDI submission.
> >
> >I would suggest that a reasonableness check for the range of valid values
> >for at a minimum the month and day components of the full 8-digit date is
> >well within the scope of this type of testing. Since the field is
> >semantically defined as birth date, a resonableness check may become a bit
> >problematic unless one's system would impose a limit of no birth year
ealier
> >than some reasonable year designation.
> >
> >Rachel
> >
> >Rachel Foerster
> >Rachel Foerster & Associates, Ltd.
> >Voice: 847-872-8070
> >email: <mailto:
> >
> >
> >-----Original Message-----
> From: Mike Rawlins [mailto:
> >Sent: Thursday, December 04, 2003 3:41 PM
> >To:
> >Subject: Re: [EDI-L] HIPAA: Does use of a qualifier mean validation should
> >be done?
> >
> >
> >X12C received a formal request for interpretation on exactly this point
> >sometime in the past year or two. Our official response was that this is
> >not a syntax error. The relationship between DMG01 and DMG02 is specified
> >in a *semantic* note, and there is no provision for generating syntax
> >errors (reportable in a 997) from a semantic note.
> >
> >I can't speak to how Claredi works, but if they classify a "Level 1 Error -
> >against X12 Standard Requirements" as applying to non-compliance with
> >semantic notes, then I suppose it is correct. In addition, an
> >implementation guide could certainly call something like this
> >non-compliance. However, there's nothing in X12.6, the segment dictionary,
> >or data element dictionary to formally call your example an "error".
> >
> >Contact me off-line if you need more info or a copy of the response.
> >
> >Mike
> >
> >At 09:17 PM 12/4/2003 +0000, anthonybeecher wrote:
> > >I am trying to classify an error level for a rejected data element,
> > >DMG02, where DMG01 is "D8" and the data value in DMG02 is "19999999";
> > >obviously there is no month 99 and no day 99.
> > >
> > >Claredi calls it a Level 1 error - against X12 Standard Requirements.
> > >I disagree with this assessment.
> > >
> > >In my mind, the only validation that is required relative to X12
> > >Syntax Requirements is that the field is type AN and sized from 1 to
> > >35 bytes.
> > >
> > > >From a pure X12 standpoint, does the use of a qualifier imply a
> > >forced validation of the format of the data element that it
> > >qualifies?
> > >
> > >I guess the possible answers would be:
> > >1. no validation is required; only X12 AN and 1-35 applies
> > >2. validation is required that 8 numeric values exist
> > >3. validation is required that 8 numeric values exist and the
> > >subportions are expressing proper ranges 1-12 for MM and 1-31 for DD
> > >4. If 3 - then leap year rules also apply?
> > >
> > >Thanks
> > >Anthony Beecher
Cart
