OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-cppa] WEDi/SNIP Electronic Trading Partner Agreements forHIPAA


Dale:

"Do you know whether HIPAA/WEDi/SNIP intends to adopt or create a way of
specifying business processes?"

We're not even able to establish formal business collaborations, as
HIPAA EDI is very X12 message centric.  It doesn't really lend itself to
the one-for-one request-response paradigm - except maybe in the case of
the eligibility request-response pair (X12 270/271) that might be
conducted in "real-time." Healthcare administration (HIPAA) EDI has not
really established any formalized approach to requirements analysis, use
case development, etc., at all.  It's just EDI messages back and forth.

Unlike the supply chain side of the business, where at least you have a
PO Ack to answer a PO, you can't really say an 837 "claim" (which is a
misnomer: the 837 might contain many claims for many providers to a
payer, depending on whether aggregation is done by a billing service)
even has a single remittance response.  See the dialog that goes back
and forth about "business processes" in the thread entitled "Re:
Requirements Gathering - Information Flows" at
http://www.mail-archive.com/routing%40wedi.org/ - especially those
written by myself or Dave Minch.  At this time, I doubt we're going to
make much use of the BP specifications - unless someone in BP can help
us figure out some way to "choreograph" the mandated HIPAA X12
transactions!

As far as the CPP-CPA is concerned, we're interested in a lot of stuff,
like security profiles and policies, including support of both PGP and
X.509, signing of the e-TPA, alternative messaging services and
packaging for supporting "legacy" protocols (especially  FTP, EDIINT AS1
and AS2, EDI value-added networks and Healthcare Clearinghouses),
specifications for payload compression (some X12 837 claims documents
can grow to megabytes), and selection of delivery channels depending on
the type of transaction to be sent (e.g., batch vs. real-time).

We also need mechanized versions of the stuff you'd expect to see in a
paper TPA, like EDI contact information.  Throw in references to
EDI-centric information we use in HIPAA - like machine readable
"companion documents" which augment situational element and segment
notes in the HIPAA implementation guides, and notations which indicate
which X12 documents are supported (a provider may say he uses 837s, but
accepts only paper remittances - he can pick and choose).  In addition,
the PartyId OASIS URI will have to accommodate those ID domains used in
Healthcare: e.g., DUNS, FEIN, HIN, NAIC Company Code, HCFA carrier ID,
HCFA Fiscal Intermediary Identification Number, Medicare Provider
Number, etc.

Even though healthcare claims are processed by "value-added"
intermediaries (such as re-pricers and reviewers), I have no idea
whether multi-hop will be applicable to us (even though ebXML MS is a
transport option, I doubt it will be used much in the next few years in
Healthcare).

Is this enough to get a discussion flowing for exploring our
requirements?  Sorry, but we can't change the X12 flavor of HIPAA -
that's cast in concrete by legislation!

William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320

----- Original Message -----
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "William J. Kammerer" <wkammerer@novannet.com>; "OASIS ebxml-cppa"
<ebxml-cppa@lists.oasis-open.org>
Sent: Wednesday, 06 March, 2002 06:20 PM
Subject: RE: [ebxml-cppa] WEDi/SNIP Electronic Trading Partner
Agreements for HIPAA


Hi,

We are still wrapping up details connected with 2.0, and we have active
commitments to work on:

1. Oasis CPPA Negotiation protocol
2. BTP role capability and agreement representation.

All other possible work items are still being prioritized, such as what
are the requirements for agreements concerning Core Component "Contexts"

We do have several futures projects that might be relevant to the e-TPA
initiative you describe.

3. We want to attempt to provide support for specific business process
or service flow representations beyond BPSS.
4. We want to be able to discuss security and transport bindings for
other "protocol profiles" beyond ebXML Messaging.

There is no data type restriction for payloads within ebXML, so I do not
anticipate use of EDI style syntaxes for the payload data to be an
issue.

Do you know whether HIPAA/WEDi/SNIP intends to adopt or create a way of
specifying business processes? Will there just be document names?

We might still be able to work out conventions for that use case and
subsume it under future project 3; we will need to decide how to refer
to Service and Action names, and what to say about the
ProcessSpecification, for example.

It might be worthwhile to start a discussion mailing thread devoted to
exploring your requirements. Do you think that would be useful?

Bye
Dale Moberg
TC Chair





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC