William,

I don't believe my comments inferred that this group is developing software.
My comments inferred that it's not the software developers that determine
requirements. Rather, its the business users that must first
determine/specify their requirements that can then be turned into functional
requirements for software developers.

My question was and still remains that trying to determine new data elements
for the ebXML CPP spec is a bit premature without first having determined
what the requirements (as yet not specified) to solve a problem (as yet
undefined) for HIPAA electronic transactions implementation by the required
compliance dates. Seems to be there are several carts in front of a horse
here.

Rachel

-----Original Message-----
From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 08, 2002 8:11 AM
To: WEDi/SNIP ID & Routing
Subject: Re: CPP Data elements draft for comment


Rachel:

We're not developing software.  We're developing recommendations for the
use of the ebXML Registry and CPP (Electronic Partner Profile) in the
HIPAA Healthcare arena. Admittedly, there's a lot of similarity between
software development and standards development, but that point needs to
be clarified.

Additionally, we would hope that any software needed to implement our
recommendations would be available off-the-shelf, from ebXML (or EDI
Translator) software vendors. The only "software" that this group might
conceivably "develop" are non-normative XSLT style-sheets which can be
used to render the Healthcare CPP in a human-readable format on any Web
browser.

Many folks on this list have contributed what, in effect, are
"requirements."  It would help if the requirements were organized,
normalized and prioritized in the working papers.  But we have
requirements, nonetheless.  For example, Kepa has raised the issue of
certification capabilities, and I see that Chris Feahr, Dick Brooks and
Dave Minch have added stuff pertaining to certification to their
"Elements of the Healthcare Collaboration-Protocol Profile (CPP)."

Whether a few field names really satisfy the "requirement" is another
matter, but it looks like the requirement wasn't forgotten.  Sometimes a
spreadsheet is kind of clumsy for expressing relationships, but I know
that Chris - bless him - has even been futzing with a UML diagram; see
http://www.novannet.com/wedi/Healthcare_CPP_Model.jpg.

Developing the spreadsheet is an integral part of enumerating
requirements: what's the problem?

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

----- Original Message -----
From: "Rachel Foerster" <[EMAIL PROTECTED]>
To: "'WEDI/SNIP Listserve'" <[EMAIL PROTECTED]>
Sent: Tuesday, 07 May, 2002 11:34 AM
Subject: RE: CPP Data elements draft for comment


Michael,

We should be asking the **real** users how they want to conduct business
(= requirements!!!) Then the software developers should provide
solutions to enable the business requirements. Software developers
should not/are not capable of determining the business requirements and
the business process requirements. They only provide solutions that
enable the process to execute to the determined/expected outcome or deal
appropriately with exceptions.

Rachel


Reply via email to