William Kammerer told us that:
> As with any man-made artifact, the HIPAA guidelines do indeed have ambiguity
> ... or outright errors. None of us is perfect, including the authors of the
> guideline or the HIPAA rules themselves. Nor, more importantly, would
> perfection be cost-effective as we're not talking about jet engine turbine
> blades here. There are plenty of chances to correct errors in the HIPAA
> business documents (e.g., claims, payments, eligibility benefits, claim
> status, or enrollment) with phone calls, letters and appeals; the worst case
> is that payment is delayed ...
I have to disagree with William here on two counts:
a. it is wholly unacceptable for anyone involved in the rule making process
to condone or overlook any known ambiguity or error simply because there
will be plenty of chances to correct these - presumably in a future issue
if the rules. Any delays, litigation costs, even future committee time
and re-publication of the documents is all done at the public expense;
bodies such as the DHSS have an extra duty of public care to ensure that
their work product is as good as it can possibly be.
b. the worst case is surely not that payment is delayed - if an insurance
company's computer bounces or delays response to a claim status enquiry
until, say, the next working day when a member of staff can pick up the
phone to resolve the issue, then someone's emergency treatment or surgery
might be delayed or postponed or a cheaper but less-effective procedure
carried out which might leave side-effects. This could in the worst case
prove fatal or result in long-term disability. Then apart from the
ensuing litigation, there would also be the human trauma and tragedy.
> HL7 clinical EDI, on the other hand, is used to support diagnosis and
> treatment, and concomitantly must provide fewer opportunities for ambiguity.
As long as healthcare is provided on a fee-paying basis, where the level or
availability of treatment depends on the ability to pay or the level of
insurance cover in place, there will always be a point at which a clinical
decision must pass to a financial decision. The X12 transactions carry the
financial (and some clinical, since that too is passed to the insurers to
enable them to make their eligibility decisions) data from provider to
payer and back - in the patients' interests those designing and controlling
those transactions have just as much duty of care as those performing
similar functions with HL7 transactions.
> It seems that the NM1 in the Other Payer Patient Information loop (2330C)
> has the NM103 (Individual last name or organizational name) marked as
> "Required," though that makes no sense considering the NM1 in this case
> is used to provide additional identifiers for an already known entity.
It is just such an error that could cause a computer, simply and blindly
following the rules in its mapping tables, to reject an otherwise valid
and urgent transaction requesting financial permission to treat a patient.
The rejection will take time to return to the originator, whose EDI staff
(at this level of knowledge) probably only work days, and in the meantime
the patient's treatment is delayed ... It is somewhat cold comfort to the
patient to know that the demand for the NM1 segment makes no sense !
> Instead, calm minds decided this was a small error in the documentation.
I am glad those concerned can consider such a small error with a calm mind.
If it were one of their spouses, parents or children on the other side of
the "small error" then I think that they might find themselves somewhat more
exercised in the matter.
Jonathan
------------------------------------------------------------------------------
Jonathan Allen | [EMAIL PROTECTED] | Voice: 01404-823670
Barum Computer Consultants | | Fax: 01404-823671
------------------------------------------------------------------------------
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
