Re: data sets

[Liora Alschuler <liora@the-word-electric.com>]

Hi, Michael,

I'm writing this from NYC, so hopefully we can straighten some of this out 
f2f at the staging/demo. Some responses below.

At 03:26 PM 4/7/01 -0700, Michael Joya wrote:
>Liora Alschuler wrote:
> >
> > Per the request made yesterday, I will be posting the HL7 DTDs and sample
> > data shortly.

hmmm, posted the sample data on Friday, didn't see it come up, so sent a 
second post with samples to Sid & Philippe. Anyone have any idea what 
limits posting of attachments to this list?

>This is data created for our demo last February. We will
> > create new data for ebXML, however, I need to know how many data sets will
> > be used. Can someone give me an idea of how many data sets were used in
> > previous demos?

Still don't know the answer to that one.


>   In the automotive scenario there was an advance shipment notification 
> document [?terminology?] and a corresponding receipt document. These were 
> the only two payloads that I used in the runtime track.
>
>   I'd like to make the advance request that the payloads in Vienna be 
> kept -as simple as possible-. Ideally we'd all have small mockup 
> application/gui that creates the message payload data dynamically, rather 
> than reading a static file and sending it down the wire. Real HL7 
> applications would be nice, but the integration work required to 
> ebXML-ize legacy apps would require more resources than a typical vendor 
> would be willing to commit.

Since HL7 apps are developed to work in an XML messaging environment, I'm 
not sure that there is a great deal of integration work required.


>   Suppose a mockup HL7 dtd contained 5-10 elements per message. You would 
> be addressing two very important concerns:

Unfortunately, you would not be addressing use of ebXML for healthcare -- 
it would remain in the realm of the theoretical. If length of payload is a 
real limitation, however, let's face it now and say that the ebXML POC 
can't handle HL7 payloads, or payloads greater than 5-10 elements, at this 
time.


>* The vendors have a better shot at implementing a nice looking 
>gui/application that can generate the payload data dynamically, meaning a 
>user form that the audience can grasp and visually connect to the 
>underlying message data. [Killdara and Schemantix are some of the few 
>vendors that can do automatic form-rendering for xml data, where most of 
>us have to invent a new form per payload.]
>
>* The "lightweight" and "easily adopted" marketing themes of ebXML 
>messaging shine through.  At the same time, we show how HL7's lives have 
>been made easier through adoption of a standard. [I feel as though the 
>2-page xml receipt I flashed to the London audience didn't impact as well 
>as a 'paragraph' of XML would have.]
>
>   In short, are you open to counterproposals on your schemas?

Personally, yes, but the payloads are HL7/ANSI specs, so there are limits 
to what we can trim off. In the zip file I tried to send on Friday, there 
is a "minimal" encounter note. The sample registration and lab messages are 
also about as small as they can get.

Perhaps if I understood the type of constraint posed by a payload larger 
than 10 elements I could help solve this issue. By most measures, these are 
relatively short, uncomplex XML documents.

regards,

Liora


>
>   Sig: my points are not exclusive to the HL7 scenario. Are schemas 
> available for the rest of the runtime presentation?
>
>
>--
>// Michael Joya
>// XML Global Research and Development
>// 1818 Cornwall Ave. Suite 9
>// Vancouver, Canada
>// 604-717-1100x230