Quantcast

HL7 parsing problem

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

HL7 parsing problem

John DeStefano-3
Hi,

Some fields in HL7 segments have repeating data in them. For example in the PID-13 there can be multiple phone numbers.
The ~ indicates a repeating field.

PID|||2111111^^^CMC||KOSKO          ^BART           ^ ^^^||19600305|F||4|SOME ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|

A repeating field can be composed of sub components.

PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR         ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||  

Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .

Is there a way to parse these fields. A feild with repeating data may or may not have sub components.

Tx


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

Tom Fennelly
Hi John.

I don't think there's a way of specifying cardinality on components or
sub-components.  Any ideas Bard?  This is probably something that we
need to be able to support in the parser.  Is there a formal description
in a spec somewhere that describes the structures involved here, or is
it a bit adhoc?

If you can tell us more about what you're trying to do then we might be
able to suggest a way of solving it with the existing codebase.  If you
are using Smooks (and not just the EDI parser), then you would have
other options to get around this.  After defining that field as being a
single field in the EDI mapping, you might then have the following options:

   1. If you're binding the hl7 data into a Java object model, then you
      could implement a decoder to parse this particular field into it's
      parts (separated by the '~' delimiter).
   2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
      process that XML fragment.

Regards,

T.


It does look a little strange

John DeStefano wrote:

> Hi,
>
> Some fields in HL7 segments have repeating data in them. For example in the PID-13 there can be multiple phone numbers.
> The ~ indicates a repeating field.
>
> PID|||2111111^^^CMC||KOSKO          ^BART           ^ ^^^||19600305|F||4|SOME ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>
> A repeating field can be composed of sub components.
>
> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR         ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||  
>
> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>
> Is there a way to parse these fields. A feild with repeating data may or may not have sub components.
>
> Tx
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

Ukyo Virgden-2
Hi Tom,

Take a look at the HL7 component of open-esb.  http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC 
  You're right just like EDI HL7 would require its own parser.

Regards,
Ukyo.

On 31.Ara.2008, at 11:07, Tom Fennelly wrote:

> Hi John.
>
> I don't think there's a way of specifying cardinality on components  
> or sub-components.  Any ideas Bard?  This is probably something that  
> we need to be able to support in the parser.  Is there a formal  
> description in a spec somewhere that describes the structures  
> involved here, or is it a bit adhoc?
>
> If you can tell us more about what you're trying to do then we might  
> be able to suggest a way of solving it with the existing codebase.  
> If you are using Smooks (and not just the EDI parser), then you  
> would have other options to get around this.  After defining that  
> field as being a single field in the EDI mapping, you might then  
> have the following options:
>
>  1. If you're binding the hl7 data into a Java object model, then you
>     could implement a decoder to parse this particular field into it's
>     parts (separated by the '~' delimiter).
>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>     process that XML fragment.
>
> Regards,
>
> T.
>
>
> It does look a little strange
>
> John DeStefano wrote:
>> Hi,
>>
>> Some fields in HL7 segments have repeating data in them. For  
>> example in the PID-13 there can be multiple phone numbers.
>> The ~ indicates a repeating field.
>>
>> PID|||2111111^^^CMC||KOSKO          ^BART           ^ ^^^||19600305|
>> F||4|SOME ROAD^^FARMINGTON^CT^060320000^^^||
>> (888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|
>> 123456789||||||||^^^^^|
>>
>> A repeating field can be composed of sub components.
>>
>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        
>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||
>> 9999^DOCTOR         ^UNKNOWN ^^^^^HHADT|NS|000040007320|
>> P~||||||||||||||||
>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>
>> Is there a way to parse these fields. A feild with repeating data  
>> may or may not have sub components.
>>
>> Tx
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

Tom Fennelly
Ah OK, thanks Ukyo.

So are you saying that the EDIParser we have will not work for HL7 and
that HL7 needs something different?  What are the big differences
between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
EDI format :(

Regards,

T.


Ukyo Virgden wrote:

> Hi Tom,
>
> Take a look at the HL7 component of open-esb.  
> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
> like EDI HL7 would require its own parser.
>
> Regards,
> Ukyo.
>
> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>
>> Hi John.
>>
>> I don't think there's a way of specifying cardinality on components
>> or sub-components.  Any ideas Bard?  This is probably something that
>> we need to be able to support in the parser.  Is there a formal
>> description in a spec somewhere that describes the structures
>> involved here, or is it a bit adhoc?
>>
>> If you can tell us more about what you're trying to do then we might
>> be able to suggest a way of solving it with the existing codebase.  
>> If you are using Smooks (and not just the EDI parser), then you would
>> have other options to get around this.  After defining that field as
>> being a single field in the EDI mapping, you might then have the
>> following options:
>>
>>  1. If you're binding the hl7 data into a Java object model, then you
>>     could implement a decoder to parse this particular field into it's
>>     parts (separated by the '~' delimiter).
>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>     process that XML fragment.
>>
>> Regards,
>>
>> T.
>>
>>
>> It does look a little strange
>>
>> John DeStefano wrote:
>>> Hi,
>>>
>>> Some fields in HL7 segments have repeating data in them. For example
>>> in the PID-13 there can be multiple phone numbers.
>>> The ~ indicates a repeating field.
>>>
>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>> ^^^||19600305|F||4|SOME
>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>
>>>
>>> A repeating field can be composed of sub components.
>>>
>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        
>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR        
>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>
>>> Is there a way to parse these fields. A feild with repeating data
>>> may or may not have sub components.
>>>
>>> Tx
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

John DeStefano-3
In reply to this post by John DeStefano-3
Hi,

The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.

Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.

I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.

Tx

>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
Ah OK, thanks Ukyo.

So are you saying that the EDIParser we have will not work for HL7 and
that HL7 needs something different?  What are the big differences
between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
EDI format :(

Regards,

T.


Ukyo Virgden wrote:

> Hi Tom,
>
> Take a look at the HL7 component of open-esb.  
> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
> like EDI HL7 would require its own parser.
>
> Regards,
> Ukyo.
>
> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>
>> Hi John.
>>
>> I don't think there's a way of specifying cardinality on components
>> or sub-components.  Any ideas Bard?  This is probably something that
>> we need to be able to support in the parser.  Is there a formal
>> description in a spec somewhere that describes the structures
>> involved here, or is it a bit adhoc?
>>
>> If you can tell us more about what you're trying to do then we might
>> be able to suggest a way of solving it with the existing codebase.  
>> If you are using Smooks (and not just the EDI parser), then you would
>> have other options to get around this.  After defining that field as
>> being a single field in the EDI mapping, you might then have the
>> following options:
>>
>>  1. If you're binding the hl7 data into a Java object model, then you
>>     could implement a decoder to parse this particular field into it's
>>     parts (separated by the '~' delimiter).
>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>     process that XML fragment.
>>
>> Regards,
>>
>> T.
>>
>>
>> It does look a little strange
>>
>> John DeStefano wrote:
>>> Hi,
>>>
>>> Some fields in HL7 segments have repeating data in them. For example
>>> in the PID-13 there can be multiple phone numbers.
>>> The ~ indicates a repeating field.
>>>
>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>> ^^^||19600305|F||4|SOME
>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>
>>>
>>> A repeating field can be composed of sub components.
>>>
>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        
>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR        
>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>
>>> Is there a way to parse these fields. A feild with repeating data
>>> may or may not have sub components.
>>>
>>> Tx
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

Tom Fennelly
Ah OK, thanks John.

So what if it was possible to define a field definition in one of 2 ways
(mutually exclusive):

   1. (As is) Containing optional field components.
   2. (New) Containing a "split-field" definition that defines how the
      field value is to be split, including a reference to the field
      that defines the split delimiter (e.g. the MSH in the example you
      gave below), cardinality etc.

#2 above might be something like....

    <medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
    </medi:field>
     

The XSD could enforce the rule that the field definition can only
contain 1 or more <medi:component> elements, or exactly
1<medi:split-field>, or nothing.

Regards,

T.


John DeStefano wrote:

> Hi,
>
> The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.
>
> Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.
>
> I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.
>
> Tx
>
>  
>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>        
> Ah OK, thanks Ukyo.
>
> So are you saying that the EDIParser we have will not work for HL7 and
> that HL7 needs something different?  What are the big differences
> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
> EDI format :(
>
> Regards,
>
> T.
>
>
> Ukyo Virgden wrote:
>  
>> Hi Tom,
>>
>> Take a look at the HL7 component of open-esb.  
>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
>> like EDI HL7 would require its own parser.
>>
>> Regards,
>> Ukyo.
>>
>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>
>>    
>>> Hi John.
>>>
>>> I don't think there's a way of specifying cardinality on components
>>> or sub-components.  Any ideas Bard?  This is probably something that
>>> we need to be able to support in the parser.  Is there a formal
>>> description in a spec somewhere that describes the structures
>>> involved here, or is it a bit adhoc?
>>>
>>> If you can tell us more about what you're trying to do then we might
>>> be able to suggest a way of solving it with the existing codebase.  
>>> If you are using Smooks (and not just the EDI parser), then you would
>>> have other options to get around this.  After defining that field as
>>> being a single field in the EDI mapping, you might then have the
>>> following options:
>>>
>>>  1. If you're binding the hl7 data into a Java object model, then you
>>>     could implement a decoder to parse this particular field into it's
>>>     parts (separated by the '~' delimiter).
>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>     process that XML fragment.
>>>
>>> Regards,
>>>
>>> T.
>>>
>>>
>>> It does look a little strange
>>>
>>> John DeStefano wrote:
>>>      
>>>> Hi,
>>>>
>>>> Some fields in HL7 segments have repeating data in them. For example
>>>> in the PID-13 there can be multiple phone numbers.
>>>> The ~ indicates a repeating field.
>>>>
>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>> ^^^||19600305|F||4|SOME
>>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>
>>>>
>>>> A repeating field can be composed of sub components.
>>>>
>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        
>>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR        
>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>
>>>> Is there a way to parse these fields. A feild with repeating data
>>>> may or may not have sub components.
>>>>
>>>> Tx
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

John DeStefano-3
In reply to this post by John DeStefano-3
Hi Tom,

Yes, that could work. You could define the repeat delimiter with the other delimiters (field, component, sub-component). In the case of HL7 this is almost always the ~. In the split-field you must also be able to define components and sub-components.

<medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="md-name" delimiter="~" maxOccurs="5" truncate="true">
               <medi:component xmltag="first-name" />
               <medi:component xmltag="last-name" />
               <medi:component xmltag="street" />
               <medi:component xmltag="city" />
               <medi:component xmltag="state" />
        </medi-split-field>
</medi:field>

Tx

>>> Tom Fennelly <[hidden email]> 01/01/09 11:11 AM >>>
Ah OK, thanks John.

So what if it was possible to define a field definition in one of 2 ways
(mutually exclusive):

   1. (As is) Containing optional field components.
   2. (New) Containing a "split-field" definition that defines how the
      field value is to be split, including a reference to the field
      that defines the split delimiter (e.g. the MSH in the example you
      gave below), cardinality etc.

#2 above might be something like....

    <medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
    </medi:field>
     

The XSD could enforce the rule that the field definition can only
contain 1 or more <medi:component> elements, or exactly
1<medi:split-field>, or nothing.

Regards,

T.


John DeStefano wrote:

> Hi,
>
> The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.
>
> Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.
>
> I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.
>
> Tx
>
>  
>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>        
> Ah OK, thanks Ukyo.
>
> So are you saying that the EDIParser we have will not work for HL7 and
> that HL7 needs something different?  What are the big differences
> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
> EDI format :(
>
> Regards,
>
> T.
>
>
> Ukyo Virgden wrote:
>  
>> Hi Tom,
>>
>> Take a look at the HL7 component of open-esb.  
>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
>> like EDI HL7 would require its own parser.
>>
>> Regards,
>> Ukyo.
>>
>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>
>>    
>>> Hi John.
>>>
>>> I don't think there's a way of specifying cardinality on components
>>> or sub-components.  Any ideas Bard?  This is probably something that
>>> we need to be able to support in the parser.  Is there a formal
>>> description in a spec somewhere that describes the structures
>>> involved here, or is it a bit adhoc?
>>>
>>> If you can tell us more about what you're trying to do then we might
>>> be able to suggest a way of solving it with the existing codebase.  
>>> If you are using Smooks (and not just the EDI parser), then you would
>>> have other options to get around this.  After defining that field as
>>> being a single field in the EDI mapping, you might then have the
>>> following options:
>>>
>>>  1. If you're binding the hl7 data into a Java object model, then you
>>>     could implement a decoder to parse this particular field into it's
>>>     parts (separated by the '~' delimiter).
>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>     process that XML fragment.
>>>
>>> Regards,
>>>
>>> T.
>>>
>>>
>>> It does look a little strange
>>>
>>> John DeStefano wrote:
>>>      
>>>> Hi,
>>>>
>>>> Some fields in HL7 segments have repeating data in them. For example
>>>> in the PID-13 there can be multiple phone numbers.
>>>> The ~ indicates a repeating field.
>>>>
>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>> ^^^||19600305|F||4|SOME
>>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>
>>>>
>>>> A repeating field can be composed of sub components.
>>>>
>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        
>>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR        
>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>
>>>> Is there a way to parse these fields. A feild with repeating data
>>>> may or may not have sub components.
>>>>
>>>> Tx
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SV: HL7 parsing problem

Bård Langöy
Hi,

The split-field looks good, but wouldn't it be possible to simply add a maxoccurs-attribute to field, components and sub-components. Since it is these values that can occur several times... In version 1.2 of smooks we will extend these elements with other attributes like type, length, id etc.

And then in the global Delimiter element add a new attribute for specifying the new recursive delimiter. It feels a bit unnecessary to define the same delimiter on several places (different fields) when it will be the same delimiter for the whole edi-file.

What do you think ?

Regards,
Bård

-----Ursprungligt meddelande-----
Från: John DeStefano [mailto:[hidden email]]
Skickat: den 3 januari 2009 04:23
Till: [hidden email]
Ämne: Re: [milyn-user] HL7 parsing problem

Hi Tom,

Yes, that could work. You could define the repeat delimiter with the other delimiters (field, component, sub-component). In the case of HL7 this is almost always the ~. In the split-field you must also be able to define components and sub-components.

<medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="md-name" delimiter="~" maxOccurs="5" truncate="true">
               <medi:component xmltag="first-name" />
               <medi:component xmltag="last-name" />
               <medi:component xmltag="street" />
               <medi:component xmltag="city" />
               <medi:component xmltag="state" />
        </medi-split-field>
</medi:field>

Tx

>>> Tom Fennelly <[hidden email]> 01/01/09 11:11 AM >>>
Ah OK, thanks John.

So what if it was possible to define a field definition in one of 2 ways
(mutually exclusive):

   1. (As is) Containing optional field components.
   2. (New) Containing a "split-field" definition that defines how the
      field value is to be split, including a reference to the field
      that defines the split delimiter (e.g. the MSH in the example you
      gave below), cardinality etc.

#2 above might be something like....

    <medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
    </medi:field>


The XSD could enforce the rule that the field definition can only
contain 1 or more <medi:component> elements, or exactly
1<medi:split-field>, or nothing.

Regards,

T.


John DeStefano wrote:

> Hi,
>
> The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.
>
> Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.
>
> I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.
>
> Tx
>
>
>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>
> Ah OK, thanks Ukyo.
>
> So are you saying that the EDIParser we have will not work for HL7 and
> that HL7 needs something different?  What are the big differences
> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
> EDI format :(
>
> Regards,
>
> T.
>
>
> Ukyo Virgden wrote:
>
>> Hi Tom,
>>
>> Take a look at the HL7 component of open-esb.
>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
>> like EDI HL7 would require its own parser.
>>
>> Regards,
>> Ukyo.
>>
>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>
>>
>>> Hi John.
>>>
>>> I don't think there's a way of specifying cardinality on components
>>> or sub-components.  Any ideas Bard?  This is probably something that
>>> we need to be able to support in the parser.  Is there a formal
>>> description in a spec somewhere that describes the structures
>>> involved here, or is it a bit adhoc?
>>>
>>> If you can tell us more about what you're trying to do then we might
>>> be able to suggest a way of solving it with the existing codebase.
>>> If you are using Smooks (and not just the EDI parser), then you would
>>> have other options to get around this.  After defining that field as
>>> being a single field in the EDI mapping, you might then have the
>>> following options:
>>>
>>>  1. If you're binding the hl7 data into a Java object model, then you
>>>     could implement a decoder to parse this particular field into it's
>>>     parts (separated by the '~' delimiter).
>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>     process that XML fragment.
>>>
>>> Regards,
>>>
>>> T.
>>>
>>>
>>> It does look a little strange
>>>
>>> John DeStefano wrote:
>>>
>>>> Hi,
>>>>
>>>> Some fields in HL7 segments have repeating data in them. For example
>>>> in the PID-13 there can be multiple phone numbers.
>>>> The ~ indicates a repeating field.
>>>>
>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>> ^^^||19600305|F||4|SOME
>>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>
>>>>
>>>> A repeating field can be composed of sub components.
>>>>
>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^
>>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR
>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>
>>>> Is there a way to parse these fields. A feild with repeating data
>>>> may or may not have sub components.
>>>>
>>>> Tx
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HL7 parsing problem

Tom Fennelly
In reply to this post by John DeStefano-3
Hi Stefano.

So the split field delimiter is always the same across the whole
message?  Different fields can't have different delimiters?  If it's not
the same, then wouldn't we also need to make it possible to define the
delimiter on the split-field, with the default coming from the main top
level <delimiters> definition.

Can you provide an example of how a split field can contain components
and sub-components?  I know this might be obvious (I can imagine what
you mean), but it would be nice to see an example, just to be totally
clear :)

Regards,

T.


John DeStefano wrote:

> Hi Tom,
>
> Yes, that could work. You could define the repeat delimiter with the other delimiters (field, component, sub-component). In the case of HL7 this is almost always the ~. In the split-field you must also be able to define components and sub-components.
>
> <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="md-name" delimiter="~" maxOccurs="5" truncate="true">
>                <medi:component xmltag="first-name" />
>                <medi:component xmltag="last-name" />
>                <medi:component xmltag="street" />
>                <medi:component xmltag="city" />
>                <medi:component xmltag="state" />
>         </medi-split-field>
> </medi:field>
>
> Tx
>
>  
>>>> Tom Fennelly <[hidden email]> 01/01/09 11:11 AM >>>
>>>>        
> Ah OK, thanks John.
>
> So what if it was possible to define a field definition in one of 2 ways
> (mutually exclusive):
>
>    1. (As is) Containing optional field components.
>    2. (New) Containing a "split-field" definition that defines how the
>       field value is to be split, including a reference to the field
>       that defines the split delimiter (e.g. the MSH in the example you
>       gave below), cardinality etc.
>
> #2 above might be something like....
>
>     <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
>     </medi:field>
>      
>
> The XSD could enforce the rule that the field definition can only
> contain 1 or more <medi:component> elements, or exactly
> 1<medi:split-field>, or nothing.
>
> Regards,
>
> T.
>
>
> John DeStefano wrote:
>  
>> Hi,
>>
>> The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.
>>
>> Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.
>>
>> I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.
>>
>> Tx
>>
>>  
>>    
>>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>>        
>>>>>          
>> Ah OK, thanks Ukyo.
>>
>> So are you saying that the EDIParser we have will not work for HL7 and
>> that HL7 needs something different?  What are the big differences
>> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
>> EDI format :(
>>
>> Regards,
>>
>> T.
>>
>>
>> Ukyo Virgden wrote:
>>  
>>    
>>> Hi Tom,
>>>
>>> Take a look at the HL7 component of open-esb.  
>>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
>>> like EDI HL7 would require its own parser.
>>>
>>> Regards,
>>> Ukyo.
>>>
>>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>>
>>>    
>>>      
>>>> Hi John.
>>>>
>>>> I don't think there's a way of specifying cardinality on components
>>>> or sub-components.  Any ideas Bard?  This is probably something that
>>>> we need to be able to support in the parser.  Is there a formal
>>>> description in a spec somewhere that describes the structures
>>>> involved here, or is it a bit adhoc?
>>>>
>>>> If you can tell us more about what you're trying to do then we might
>>>> be able to suggest a way of solving it with the existing codebase.  
>>>> If you are using Smooks (and not just the EDI parser), then you would
>>>> have other options to get around this.  After defining that field as
>>>> being a single field in the EDI mapping, you might then have the
>>>> following options:
>>>>
>>>>  1. If you're binding the hl7 data into a Java object model, then you
>>>>     could implement a decoder to parse this particular field into it's
>>>>     parts (separated by the '~' delimiter).
>>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>>     process that XML fragment.
>>>>
>>>> Regards,
>>>>
>>>> T.
>>>>
>>>>
>>>> It does look a little strange
>>>>
>>>> John DeStefano wrote:
>>>>      
>>>>        
>>>>> Hi,
>>>>>
>>>>> Some fields in HL7 segments have repeating data in them. For example
>>>>> in the PID-13 there can be multiple phone numbers.
>>>>> The ~ indicates a repeating field.
>>>>>
>>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>>> ^^^||19600305|F||4|SOME
>>>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>>
>>>>>
>>>>> A repeating field can be composed of sub components.
>>>>>
>>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^        
>>>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR        
>>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>>
>>>>> Is there a way to parse these fields. A feild with repeating data
>>>>> may or may not have sub components.
>>>>>
>>>>> Tx
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>        
>>>>>          
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>   http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>      
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: HL7 parsing problem

Tom Fennelly
In reply to this post by Bård Langöy
Hey Bard.

Comments inline...

Bård Langöy wrote:
> Hi,
>
> The split-field looks good, but wouldn't it be possible to simply add a maxoccurs-attribute to field, components and sub-components.
Yeah... but how would you know which field/component/ etc is which since
they are not "named"?  At the moment we only know which field/etc we're
dealing with based on it's fixed position.  It's fixed because there's a
fixed cardinality  i.e. min/max = 1.
> Since it is these values that can occur several times... In version 1.2 of smooks we will extend these elements with other attributes like type, length, id etc.
>
> And then in the global Delimiter element add a new attribute for specifying the new recursive delimiter.
Sure.. this is a good idea.  If this delimiter can be different in
different parts of the message, then we'd need to be able to locally
override the default on a field by field basis, right?

>  It feels a bit unnecessary to define the same delimiter on several places (different fields) when it will be the same delimiter for the whole edi-file.
>
> What do you think ?
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: John DeStefano [mailto:[hidden email]]
> Skickat: den 3 januari 2009 04:23
> Till: [hidden email]
> Ämne: Re: [milyn-user] HL7 parsing problem
>
> Hi Tom,
>
> Yes, that could work. You could define the repeat delimiter with the other delimiters (field, component, sub-component). In the case of HL7 this is almost always the ~. In the split-field you must also be able to define components and sub-components.
>
> <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="md-name" delimiter="~" maxOccurs="5" truncate="true">
>                <medi:component xmltag="first-name" />
>                <medi:component xmltag="last-name" />
>                <medi:component xmltag="street" />
>                <medi:component xmltag="city" />
>                <medi:component xmltag="state" />
>         </medi-split-field>
> </medi:field>
>
> Tx
>
>  
>>>> Tom Fennelly <[hidden email]> 01/01/09 11:11 AM >>>
>>>>        
> Ah OK, thanks John.
>
> So what if it was possible to define a field definition in one of 2 ways
> (mutually exclusive):
>
>    1. (As is) Containing optional field components.
>    2. (New) Containing a "split-field" definition that defines how the
>       field value is to be split, including a reference to the field
>       that defines the split delimiter (e.g. the MSH in the example you
>       gave below), cardinality etc.
>
> #2 above might be something like....
>
>     <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
>     </medi:field>
>
>
> The XSD could enforce the rule that the field definition can only
> contain 1 or more <medi:component> elements, or exactly
> 1<medi:split-field>, or nothing.
>
> Regards,
>
> T.
>
>
> John DeStefano wrote:
>  
>> Hi,
>>
>> The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.
>>
>> Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.
>>
>> I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.
>>
>> Tx
>>
>>
>>    
>>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>>
>>>>>          
>> Ah OK, thanks Ukyo.
>>
>> So are you saying that the EDIParser we have will not work for HL7 and
>> that HL7 needs something different?  What are the big differences
>> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
>> EDI format :(
>>
>> Regards,
>>
>> T.
>>
>>
>> Ukyo Virgden wrote:
>>
>>    
>>> Hi Tom,
>>>
>>> Take a look at the HL7 component of open-esb.
>>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
>>> like EDI HL7 would require its own parser.
>>>
>>> Regards,
>>> Ukyo.
>>>
>>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>>
>>>
>>>      
>>>> Hi John.
>>>>
>>>> I don't think there's a way of specifying cardinality on components
>>>> or sub-components.  Any ideas Bard?  This is probably something that
>>>> we need to be able to support in the parser.  Is there a formal
>>>> description in a spec somewhere that describes the structures
>>>> involved here, or is it a bit adhoc?
>>>>
>>>> If you can tell us more about what you're trying to do then we might
>>>> be able to suggest a way of solving it with the existing codebase.
>>>> If you are using Smooks (and not just the EDI parser), then you would
>>>> have other options to get around this.  After defining that field as
>>>> being a single field in the EDI mapping, you might then have the
>>>> following options:
>>>>
>>>>  1. If you're binding the hl7 data into a Java object model, then you
>>>>     could implement a decoder to parse this particular field into it's
>>>>     parts (separated by the '~' delimiter).
>>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>>     process that XML fragment.
>>>>
>>>> Regards,
>>>>
>>>> T.
>>>>
>>>>
>>>> It does look a little strange
>>>>
>>>> John DeStefano wrote:
>>>>
>>>>        
>>>>> Hi,
>>>>>
>>>>> Some fields in HL7 segments have repeating data in them. For example
>>>>> in the PID-13 there can be multiple phone numbers.
>>>>> The ~ indicates a repeating field.
>>>>>
>>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>>> ^^^||19600305|F||4|SOME
>>>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>>
>>>>>
>>>>> A repeating field can be composed of sub components.
>>>>>
>>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^
>>>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR
>>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>>
>>>>> Is there a way to parse these fields. A feild with repeating data
>>>>> may or may not have sub components.
>>>>>
>>>>> Tx
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>   http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: HL7 parsing problem

John DeStefano-3
Hi Guys,

As far as the HL7 repition delimiter it is always specified in the MSH
segement and does not change for a particular field. Being able to
overide it for a field would not be helpful for HL7 processing but may
be useful for other messages types?

Tx

>>> Tom Fennelly <[hidden email]> 1/5/2009 9:49 AM >>>
Hey Bard.

Comments inline...

Bård Langöy wrote:
> Hi,
>
> The split-field looks good, but wouldn't it be possible to simply add
a maxoccurs-attribute to field, components and sub-components.
Yeah... but how would you know which field/component/ etc is which
since
they are not "named"?  At the moment we only know which field/etc we're

dealing with based on it's fixed position.  It's fixed because there's
a
fixed cardinality  i.e. min/max = 1.
> Since it is these values that can occur several times... In version
1.2 of smooks we will extend these elements with other attributes like
type, length, id etc.
>
> And then in the global Delimiter element add a new attribute for
specifying the new recursive delimiter.
Sure.. this is a good idea.  If this delimiter can be different in
different parts of the message, then we'd need to be able to locally
override the default on a field by field basis, right?
>  It feels a bit unnecessary to define the same delimiter on several
places (different fields) when it will be the same delimiter for the
whole edi-file.

>
> What do you think ?
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: John DeStefano [mailto:[hidden email]]
> Skickat: den 3 januari 2009 04:23
> Till: [hidden email]
> Ämne: Re: [milyn-user] HL7 parsing problem
>
> Hi Tom,
>
> Yes, that could work. You could define the repeat delimiter with the
other delimiters (field, component, sub-component). In the case of HL7
this is almost always the ~. In the split-field you must also be able to
define components and sub-components.
>
> <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="md-name" delimiter="~"
maxOccurs="5" truncate="true">

>                <medi:component xmltag="first-name" />
>                <medi:component xmltag="last-name" />
>                <medi:component xmltag="street" />
>                <medi:component xmltag="city" />
>                <medi:component xmltag="state" />
>         </medi-split-field>
> </medi:field>
>
> Tx
>
>  
>>>> Tom Fennelly <[hidden email]> 01/01/09 11:11 AM >>>
>>>>        
> Ah OK, thanks John.
>
> So what if it was possible to define a field definition in one of 2
ways
> (mutually exclusive):
>
>    1. (As is) Containing optional field components.
>    2. (New) Containing a "split-field" definition that defines how
the
>       field value is to be split, including a reference to the field
>       that defines the split delimiter (e.g. the MSH in the example
you
>       gave below), cardinality etc.
>
> #2 above might be something like....
>
>     <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="phoneNumber" delimiter="MSH"
maxOccurs="3" />

>     </medi:field>
>
>
> The XSD could enforce the rule that the field definition can only
> contain 1 or more <medi:component> elements, or exactly
> 1<medi:split-field>, or nothing.
>
> Regards,
>
> T.
>
>
> John DeStefano wrote:
>  
>> Hi,
>>
>> The current parser handles most everything including repeating
segments fine. The major issue I have found so far is the concept of
repeating data within a field.
>>
>> Take a look at
http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This
is an older version definition of HL7 but still you can see that some of
the segments have fields that repeat a data structure within them
(PID-9, PID-11). The repeated structure is usually separated by a ~
however this is defined in the MSH field 1. The repeated structure can
also have a maximum number of repeats as in PID-11. It looks like there
needs to be some definition within a fields, maybe repeating-field that
you could define the data structure in.
>>
>> I'm trying to use Smooks with the Jboss esb to handle some HL7
messaging. The suggestions below about mapping the field into a java
object is something I intend to do with the produced XML, however, it
would be a lot more elegant to have the parsed data be a true
representation of the input message.

>>
>> Tx
>>
>>
>>    
>>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>>
>>>>>          
>> Ah OK, thanks Ukyo.
>>
>> So are you saying that the EDIParser we have will not work for HL7
and
>> that HL7 needs something different?  What are the big differences
>> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was
an

>> EDI format :(
>>
>> Regards,
>>
>> T.
>>
>>
>> Ukyo Virgden wrote:
>>
>>    
>>> Hi Tom,
>>>
>>> Take a look at the HL7 component of open-esb.
>>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right
just

>>> like EDI HL7 would require its own parser.
>>>
>>> Regards,
>>> Ukyo.
>>>
>>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>>
>>>
>>>      
>>>> Hi John.
>>>>
>>>> I don't think there's a way of specifying cardinality on
components
>>>> or sub-components.  Any ideas Bard?  This is probably something
that
>>>> we need to be able to support in the parser.  Is there a formal
>>>> description in a spec somewhere that describes the structures
>>>> involved here, or is it a bit adhoc?
>>>>
>>>> If you can tell us more about what you're trying to do then we
might
>>>> be able to suggest a way of solving it with the existing
codebase.
>>>> If you are using Smooks (and not just the EDI parser), then you
would
>>>> have other options to get around this.  After defining that field
as
>>>> being a single field in the EDI mapping, you might then have the
>>>> following options:
>>>>
>>>>  1. If you're binding the hl7 data into a Java object model, then
you
>>>>     could implement a decoder to parse this particular field into
it's

>>>>     parts (separated by the '~' delimiter).
>>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>>     process that XML fragment.
>>>>
>>>> Regards,
>>>>
>>>> T.
>>>>
>>>>
>>>> It does look a little strange
>>>>
>>>> John DeStefano wrote:
>>>>
>>>>        
>>>>> Hi,
>>>>>
>>>>> Some fields in HL7 segments have repeating data in them. For
example
>>>>> in the PID-13 there can be multiple phone numbers.
>>>>> The ~ indicates a repeating field.
>>>>>
>>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>>> ^^^||19600305|F||4|SOME
>>>>>
ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>>
>>>>>
>>>>> A repeating field can be composed of sub components.
>>>>>
>>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^
>>>>>
^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR
>>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>>
>>>>> Is there a way to parse these fields. A feild with repeating
data
>>>>> may or may not have sub components.
>>>>>
>>>>> Tx
>>>>>
>>>>>
>>>>>
---------------------------------------------------------------------

>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>
---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>   http://xircles.codehaus.org/manage_email 
>>>>
>>>>
>>>>
>>>>        
>>>
---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email 
>>>
>>>
>>>
>>>
>>>      
>>
---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email 
>>
>>
>>
>>
>>
---------------------------------------------------------------------

>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email 
>>
>>
>>
>>
>>    
>
>
---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email 
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email 
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email 
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email 



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SV: SV: HL7 parsing problem

Bård Langöy
In reply to this post by Tom Fennelly
Hi,

Tom, you wrote:
Yeah... but how would you know which field/component/ etc is which since
they are not "named"?  At the moment we only know which field/etc we're
dealing with based on it's fixed position.  It's fixed because there's a
fixed cardinality  i.e. min/max = 1.

Bård: Couldn't we simply remember the last field/component/sub-component (FCS) in the EDIParser and in the case when a recursive-delimiter shows up, the saved FCS is used and not the next in line. I must admit I haven't checked if it is possible yet, but it feels like that would be the easiest way to configure the edimap. I could take a look at it and see if it is possible.

Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 5 januari 2009 15:50
Till: [hidden email]
Ämne: Re: SV: [milyn-user] HL7 parsing problem

Hey Bard.

Comments inline...

Bård Langöy wrote:
> Hi,
>
> The split-field looks good, but wouldn't it be possible to simply add a maxoccurs-attribute to field, components and sub-components.
Yeah... but how would you know which field/component/ etc is which since
they are not "named"?  At the moment we only know which field/etc we're
dealing with based on it's fixed position.  It's fixed because there's a
fixed cardinality  i.e. min/max = 1.
> Since it is these values that can occur several times... In version 1.2 of smooks we will extend these elements with other attributes like type, length, id etc.
>
> And then in the global Delimiter element add a new attribute for specifying the new recursive delimiter.
Sure.. this is a good idea.  If this delimiter can be different in
different parts of the message, then we'd need to be able to locally
override the default on a field by field basis, right?

>  It feels a bit unnecessary to define the same delimiter on several places (different fields) when it will be the same delimiter for the whole edi-file.
>
> What do you think ?
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: John DeStefano [mailto:[hidden email]]
> Skickat: den 3 januari 2009 04:23
> Till: [hidden email]
> Ämne: Re: [milyn-user] HL7 parsing problem
>
> Hi Tom,
>
> Yes, that could work. You could define the repeat delimiter with the other delimiters (field, component, sub-component). In the case of HL7 this is almost always the ~. In the split-field you must also be able to define components and sub-components.
>
> <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="md-name" delimiter="~" maxOccurs="5" truncate="true">
>                <medi:component xmltag="first-name" />
>                <medi:component xmltag="last-name" />
>                <medi:component xmltag="street" />
>                <medi:component xmltag="city" />
>                <medi:component xmltag="state" />
>         </medi-split-field>
> </medi:field>
>
> Tx
>
>
>>>> Tom Fennelly <[hidden email]> 01/01/09 11:11 AM >>>
>>>>
> Ah OK, thanks John.
>
> So what if it was possible to define a field definition in one of 2 ways
> (mutually exclusive):
>
>    1. (As is) Containing optional field components.
>    2. (New) Containing a "split-field" definition that defines how the
>       field value is to be split, including a reference to the field
>       that defines the split delimiter (e.g. the MSH in the example you
>       gave below), cardinality etc.
>
> #2 above might be something like....
>
>     <medi:field xmltag="phoneNumbers">
>         <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
>     </medi:field>
>
>
> The XSD could enforce the rule that the field definition can only
> contain 1 or more <medi:component> elements, or exactly
> 1<medi:split-field>, or nothing.
>
> Regards,
>
> T.
>
>
> John DeStefano wrote:
>
>> Hi,
>>
>> The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.
>>
>> Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.
>>
>> I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.
>>
>> Tx
>>
>>
>>
>>>>> Tom Fennelly <[hidden email]> 12/31/08 6:21 AM >>>
>>>>>
>>>>>
>> Ah OK, thanks Ukyo.
>>
>> So are you saying that the EDIParser we have will not work for HL7 and
>> that HL7 needs something different?  What are the big differences
>> between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
>> EDI format :(
>>
>> Regards,
>>
>> T.
>>
>>
>> Ukyo Virgden wrote:
>>
>>
>>> Hi Tom,
>>>
>>> Take a look at the HL7 component of open-esb.
>>> http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
>>> like EDI HL7 would require its own parser.
>>>
>>> Regards,
>>> Ukyo.
>>>
>>> On 31.Ara.2008, at 11:07, Tom Fennelly wrote:
>>>
>>>
>>>
>>>> Hi John.
>>>>
>>>> I don't think there's a way of specifying cardinality on components
>>>> or sub-components.  Any ideas Bard?  This is probably something that
>>>> we need to be able to support in the parser.  Is there a formal
>>>> description in a spec somewhere that describes the structures
>>>> involved here, or is it a bit adhoc?
>>>>
>>>> If you can tell us more about what you're trying to do then we might
>>>> be able to suggest a way of solving it with the existing codebase.
>>>> If you are using Smooks (and not just the EDI parser), then you would
>>>> have other options to get around this.  After defining that field as
>>>> being a single field in the EDI mapping, you might then have the
>>>> following options:
>>>>
>>>>  1. If you're binding the hl7 data into a Java object model, then you
>>>>     could implement a decoder to parse this particular field into it's
>>>>     parts (separated by the '~' delimiter).
>>>>  2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
>>>>     process that XML fragment.
>>>>
>>>> Regards,
>>>>
>>>> T.
>>>>
>>>>
>>>> It does look a little strange
>>>>
>>>> John DeStefano wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Some fields in HL7 segments have repeating data in them. For example
>>>>> in the PID-13 there can be multiple phone numbers.
>>>>> The ~ indicates a repeating field.
>>>>>
>>>>> PID|||2111111^^^CMC||KOSKO          ^BART           ^
>>>>> ^^^||19600305|F||4|SOME
>>>>> ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|
>>>>>
>>>>>
>>>>> A repeating field can be composed of sub components.
>>>>>
>>>>> PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^
>>>>> ^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR
>>>>> ^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
>>>>> Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .
>>>>>
>>>>> Is there a way to parse these fields. A feild with repeating data
>>>>> may or may not have sub components.
>>>>>
>>>>> Tx
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>   http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

Tom Fennelly

Bård Langöy wrote:
Hi,

Tom, you wrote:
Yeah... but how would you know which field/component/ etc is which since
they are not "named"?  At the moment we only know which field/etc we're
dealing with based on it's fixed position.  It's fixed because there's a
fixed cardinality  i.e. min/max = 1.

Bård: Couldn't we simply remember the last field/component/sub-component (FCS) in the EDIParser and in the case when a recursive-delimiter shows up, the saved FCS is used and not the next in line. I must admit I haven't checked if it is possible yet, but it feels like that would be the easiest way to configure the edimap. I could take a look at it and see if it is possible.
  
If I understand you, I don't think that would work Bard.  It needs to be able to support cardinality on the split-field.  The way I think about it is re breaking it down from a segment.  The segment is the only thing that's actually named.  Everything else is identified by position only (the FCSs).  This is why the parser doesn't currently support cardinality on the FCSs.

So at the moment it works by:
  1. Buffer the next segment.
  2. Split out the fields using the field delimiter.  This also gives access to the field id/name.
  3. Check is the segment expected relative to the current segment.
  4. Start processing each field based on the segment spec and the field positions.
  5. For each field, split out the components using the component delimiter.  Process each component based on the field spec and the component positions.
So at the moment, processing of the FCSs is totally based on position.  This effectively means you can't support cardinality at these levels without introducing something more.

As I see it, the easiest (least intrusive) way of supporting what John needs is to introduce a little twist at the field processing level (at #5 above):
  1. Buffer the next segment.
  2. Split out the fields using the field delimiter.  This also gives access to the field id/name.
  3. Check is the segment expected relative to the current segment.
  4. Start processing each field based on the segment spec and the field positions.
  5. For each field, check is it a "split-field".  If it is, we split the field based on the split field delimiter (e.g. the '~' char).
  6. Check the split-field cardinality constraints i.e. validate the min/max split-fields.
  7. For each split-field, split out the components using the component delimiter.  Process each component based on the field spec and the component positions etc etc
I didn't mention where the split-field delimiter comes from, but that's a no-brainer.  I think we should support a split-field-delimiter in the <delimiters> definition and allow that to be overridden in the split-field def through ref to a field that specifies the delimiter, or by specifying the delimiter explicitly.  As John says, HL7 may not need all of this, but I still think it would be good to add it.

Am I missing something?

T.


Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]]
Skickat: den 5 januari 2009 15:50
Till: [hidden email]
Ämne: Re: SV: [milyn-user] HL7 parsing problem

Hey Bard.

Comments inline...

Bård Langöy wrote:
  
Hi,

The split-field looks good, but wouldn't it be possible to simply add a maxoccurs-attribute to field, components and sub-components.
    
Yeah... but how would you know which field/component/ etc is which since
they are not "named"?  At the moment we only know which field/etc we're
dealing with based on it's fixed position.  It's fixed because there's a
fixed cardinality  i.e. min/max = 1.
  
Since it is these values that can occur several times... In version 1.2 of smooks we will extend these elements with other attributes like type, length, id etc.

And then in the global Delimiter element add a new attribute for specifying the new recursive delimiter.
    
Sure.. this is a good idea.  If this delimiter can be different in
different parts of the message, then we'd need to be able to locally
override the default on a field by field basis, right?
  
 It feels a bit unnecessary to define the same delimiter on several places (different fields) when it will be the same delimiter for the whole edi-file.

What do you think ?

Regards,
Bård

-----Ursprungligt meddelande-----
Från: John DeStefano [[hidden email]]
Skickat: den 3 januari 2009 04:23
Till: [hidden email]
Ämne: Re: [milyn-user] HL7 parsing problem

Hi Tom,

Yes, that could work. You could define the repeat delimiter with the other delimiters (field, component, sub-component). In the case of HL7 this is almost always the ~. In the split-field you must also be able to define components and sub-components.

<medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="md-name" delimiter="~" maxOccurs="5" truncate="true">
               <medi:component xmltag="first-name" />
               <medi:component xmltag="last-name" />
               <medi:component xmltag="street" />
               <medi:component xmltag="city" />
               <medi:component xmltag="state" />
        </medi-split-field>
</medi:field>

Tx


    
Tom Fennelly [hidden email] 01/01/09 11:11 AM >>>

          
Ah OK, thanks John.

So what if it was possible to define a field definition in one of 2 ways
(mutually exclusive):

   1. (As is) Containing optional field components.
   2. (New) Containing a "split-field" definition that defines how the
      field value is to be split, including a reference to the field
      that defines the split delimiter (e.g. the MSH in the example you
      gave below), cardinality etc.

#2 above might be something like....

    <medi:field xmltag="phoneNumbers">
        <medi:split-field xmltag="phoneNumber" delimiter="MSH" maxOccurs="3" />
    </medi:field>


The XSD could enforce the rule that the field definition can only
contain 1 or more <medi:component> elements, or exactly
1<medi:split-field>, or nothing.

Regards,

T.


John DeStefano wrote:

    
Hi,

The current parser handles most everything including repeating segments fine. The major issue I have found so far is the concept of repeating data within a field.

Take a look at http://aurora.regenstrief.org/~gunther/oldhtml/segments.html . This is an older version definition of HL7 but still you can see that some of the segments have fields that repeat a data structure within them (PID-9, PID-11). The repeated structure is usually separated by a ~ however this is defined in the MSH field 1. The repeated structure can also have a maximum number of repeats as in PID-11. It looks like there needs to be some definition within a fields, maybe repeating-field that you could define the data structure in.

I'm trying to use Smooks with the Jboss esb to handle some HL7 messaging. The suggestions below about mapping the field into a java object is something I intend to do with the produced XML, however, it would be a lot more elegant to have the parsed data be a true representation of the input message.

Tx



      
Tom Fennelly [hidden email] 12/31/08 6:21 AM >>>


            
Ah OK, thanks Ukyo.

So are you saying that the EDIParser we have will not work for HL7 and
that HL7 needs something different?  What are the big differences
between HL7 and EDI.  Excuse my ignorance.  I always thought HL7 was an
EDI format :(

Regards,

T.


Ukyo Virgden wrote:


      
Hi Tom,

Take a look at the HL7 component of open-esb.
http://wiki.open-esb.java.net/Wiki.jsp?page=HL7BC You're right just
like EDI HL7 would require its own parser.

Regards,
Ukyo.

On 31.Ara.2008, at 11:07, Tom Fennelly wrote:



        
Hi John.

I don't think there's a way of specifying cardinality on components
or sub-components.  Any ideas Bard?  This is probably something that
we need to be able to support in the parser.  Is there a formal
description in a spec somewhere that describes the structures
involved here, or is it a bit adhoc?

If you can tell us more about what you're trying to do then we might
be able to suggest a way of solving it with the existing codebase.
If you are using Smooks (and not just the EDI parser), then you would
have other options to get around this.  After defining that field as
being a single field in the EDI mapping, you might then have the
following options:

 1. If you're binding the hl7 data into a Java object model, then you
    could implement a decoder to parse this particular field into it's
    parts (separated by the '~' delimiter).
 2. Implement a custom Smooks Visitor (SAXVisitor/DOMVisitor) to
    process that XML fragment.

Regards,

T.


It does look a little strange

John DeStefano wrote:


          
Hi,

Some fields in HL7 segments have repeating data in them. For example
in the PID-13 there can be multiple phone numbers.
The ~ indicates a repeating field.

PID|||2111111^^^CMC||KOSKO          ^BART           ^
^^^||19600305|F||4|SOME
ROAD^^FARMINGTON^CT^060320000^^^||(888)123-4356~(999)555-5555|||D||000041111111^^M10^CMC|123456789||||||||^^^^^|


A repeating field can be composed of sub components.

PV1||O|    ^      ^  ^HH^|||^^^^|    ^               ^
^^^^^HHADT|^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~|ORT|^^^^|||RA|||9999^DOCTOR
^UNKNOWN ^^^^^HHADT|NS|000040007320|P~||||||||||||||||
Notice the field ^^^^^^^|^^^^^^^~^^^^^^^~^^^^^^^~^^^^^^^~ .

Is there a way to parse these fields. A feild with repeating data
may or may not have sub components.

Tx


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






            
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




          
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





        
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





      
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




    

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

cozyroc
Tom,

I wanted to find out what has happened since? I haven't found any work items published in the tracking system and the discussion hasn't been active for more than a year.

TomFennelly wrote
Bård Langöy wrote:
> Hi,
>
> Tom, you wrote:
> Yeah... but how would you know which field/component/ etc is which since
> they are not "named"?  At the moment we only know which field/etc we're
> dealing with based on it's fixed position.  It's fixed because there's a
> fixed cardinality  i.e. min/max = 1.
>
> Bård: Couldn't we simply remember the last field/component/sub-component (FCS) in the EDIParser and in the case when a recursive-delimiter shows up, the saved FCS is used and not the next in line. I must admit I haven't checked if it is possible yet, but it feels like that would be the easiest way to configure the edimap. I could take a look at it and see if it is possible.
>  
If I understand you, I don't think that would work Bard.  It needs to be
able to support cardinality on the split-field.  The way I think about
it is re breaking it down from a segment.  The segment is the only thing
that's actually named.  Everything else is identified by position only
(the FCSs).  This is why the parser doesn't currently support
cardinality on the FCSs.

So at the moment it works by:

   1. Buffer the next segment.
   2. Split out the fields using the field delimiter.  This also gives
      access to the field id/name.
   3. Check is the segment expected relative to the current segment.
   4. Start processing each field based on the segment spec and the
      field positions.
   5. For each field, split out the components using the component
      delimiter.  Process each component based on the field spec and the
      component positions.

So at the moment, processing of the FCSs is totally based on position.  
This effectively means you can't support cardinality at these levels
without introducing something more.

As I see it, the easiest (least intrusive) way of supporting what John
needs is to introduce a little twist at the field processing level (at
#5 above):

   1. Buffer the next segment.
   2. Split out the fields using the field delimiter.  This also gives
      access to the field id/name.
   3. Check is the segment expected relative to the current segment.
   4. Start processing each field based on the segment spec and the
      field positions.
   5. /For each field, check is it a "split-field".  If it is, we split
      the field based on the split field delimiter (e.g. the '~' char)./
   6. /Check the split-field cardinality constraints i.e. validate the
      min/max split-fields.
      /
   7. /For each split-field, split out the components using the
      component delimiter.  Process each component based on the field
      spec and the component positions etc etc/

I didn't mention where the split-field delimiter comes from, but that's
a no-brainer.  I think we should support a split-field-delimiter in the
<delimiters> definition and allow that to be overridden in the
split-field def through ref to a field that specifies the delimiter, or
by specifying the delimiter explicitly.  As John says, HL7 may not need
all of this, but I still think it would be good to add it.

Am I missing something?

T.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

Tom Fennelly
Hmmm... if I follow the thread... no, nothing has been done on it.  
Classic case of the squeaky wheel(s) getting the oil and this wheel
wasn't squeaky enough :)

We're interested in doing something for HL7 if someone is able to share
the specs with us.

T.


cozyroc wrote:

> Tom,
>
> I wanted to find out what has happened since? I haven't found any work items
> published in the tracking system and the discussion hasn't been active for
> more than a year.
>
>
> TomFennelly wrote:
>  
>> Bård Langöy wrote:
>>    
>>> Hi,
>>>
>>> Tom, you wrote:
>>> Yeah... but how would you know which field/component/ etc is which since
>>> they are not "named"?  At the moment we only know which field/etc we're
>>> dealing with based on it's fixed position.  It's fixed because there's a
>>> fixed cardinality  i.e. min/max = 1.
>>>
>>> Bård: Couldn't we simply remember the last field/component/sub-component
>>> (FCS) in the EDIParser and in the case when a recursive-delimiter shows
>>> up, the saved FCS is used and not the next in line. I must admit I
>>> haven't checked if it is possible yet, but it feels like that would be
>>> the easiest way to configure the edimap. I could take a look at it and
>>> see if it is possible.
>>>  
>>>      
>> If I understand you, I don't think that would work Bard.  It needs to be
>> able to support cardinality on the split-field.  The way I think about
>> it is re breaking it down from a segment.  The segment is the only thing
>> that's actually named.  Everything else is identified by position only
>> (the FCSs).  This is why the parser doesn't currently support
>> cardinality on the FCSs.
>>
>> So at the moment it works by:
>>
>>    1. Buffer the next segment.
>>    2. Split out the fields using the field delimiter.  This also gives
>>       access to the field id/name.
>>    3. Check is the segment expected relative to the current segment.
>>    4. Start processing each field based on the segment spec and the
>>       field positions.
>>    5. For each field, split out the components using the component
>>       delimiter.  Process each component based on the field spec and the
>>       component positions.
>>
>> So at the moment, processing of the FCSs is totally based on position.  
>> This effectively means you can't support cardinality at these levels
>> without introducing something more.
>>
>> As I see it, the easiest (least intrusive) way of supporting what John
>> needs is to introduce a little twist at the field processing level (at
>> #5 above):
>>
>>    1. Buffer the next segment.
>>    2. Split out the fields using the field delimiter.  This also gives
>>       access to the field id/name.
>>    3. Check is the segment expected relative to the current segment.
>>    4. Start processing each field based on the segment spec and the
>>       field positions.
>>    5. /For each field, check is it a "split-field".  If it is, we split
>>       the field based on the split field delimiter (e.g. the '~' char)./
>>    6. /Check the split-field cardinality constraints i.e. validate the
>>       min/max split-fields.
>>       /
>>    7. /For each split-field, split out the components using the
>>       component delimiter.  Process each component based on the field
>>       spec and the component positions etc etc/
>>
>> I didn't mention where the split-field delimiter comes from, but that's
>> a no-brainer.  I think we should support a split-field-delimiter in the
>> <delimiters> definition and allow that to be overridden in the
>> split-field def through ref to a field that specifies the delimiter, or
>> by specifying the delimiter explicitly.  As John says, HL7 may not need
>> all of this, but I still think it would be good to add it.
>>
>> Am I missing something?
>>
>> T.
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

cozyroc
Tom,

I have a specific customer case where I see how the field repeater is being used. I think the naming convention is a bit confusing because the complete segment is actually repeated. Let me give an example. Let's say you have the following HL7 segment:

A|B|C~D~E

The ~ is the field repeater delimiter and it is a shorter form of the following:

A|B|C
A|B|D
A|B|E

I'm not sure if you have the same understanding of the requirement, but if your research shows the same then I think the EDI parser can be extended to handle this extra requirement like this:

1. Setup a queue list where segment buffers can be pushed on demand.
2. In the EDIParser::mapField method analyze the field, checking for field repeater delimiter. If the delimiter is there, break the field and construct new segment buffers for each  field pushing them in the queue object.
3. In the BufferedSegmentReader::moveToNextSegment method check if the queue object contains items and if so pop the first segment buffer from top and return from the method. The regular streamed reading is suspended. This will be repeated until the queue has been emptied. After this is completed, the regular streamed reading can resume.

What do you think about this approach?

p.s.
I will ask my customer if he has HL7 specification and if he can share it.

TomFennelly wrote
Hmmm... if I follow the thread... no, nothing has been done on it.  
Classic case of the squeaky wheel(s) getting the oil and this wheel
wasn't squeaky enough :)

We're interested in doing something for HL7 if someone is able to share
the specs with us.

T.


cozyroc wrote:
> Tom,
>
> I wanted to find out what has happened since? I haven't found any work items
> published in the tracking system and the discussion hasn't been active for
> more than a year.
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

Tom Fennelly
Hi Ivan.

Can we get more info on this?  How is this described within the HL7 specs?  Is this a formal construct?

Taking your example of:
A|B|C~D~E
On an application level, what is not covered if the parser generates the following for the above segment:
<theseg>
    <name>B</name>
    <stuff>
        <s1>C</s1>
        <s2>D</s2>
        <s3>E</s3>
    </stuff>
<theseg>
Functionally.... is it not possible to read that structure in the same way?

I think the main thing is that we need more info here.  I'm a bit wary of adding reader push-back type behavior in the parser.  I think that might be a slippery slope :)

T.


cozyroc wrote:
Tom,

I have a specific customer case where I see how the field repeater is being
used. I think the naming convention is a bit confusing because the complete
segment is actually repeated. Let me give an example. Let's say you have the
following HL7 segment:

A|B|C~D~E

The ~ is the field repeater delimiter and it is a shorter form of the
following:

A|B|C
A|B|D
A|B|E

I'm not sure if you have the same understanding of the requirement, but if
your research shows the same then I think the EDI parser can be extended to
handle this extra requirement like this:

1. Setup a queue list where segment buffers can be pushed on demand.
2. In the EDIParser::mapField method analyze the field, checking for field
repeater delimiter. If the delimiter is there, break the field and construct
new segment buffers for each  field pushing them in the queue object.
3. In the BufferedSegmentReader::moveToNextSegment method check if the queue
object contains items and if so pop the first segment buffer from top and
return from the method. The regular streamed reading is suspended. This will
be repeated until the queue has been emptied. After this is completed, the
regular streamed reading can resume.

What do you think about this approach?

p.s.
I will ask my customer if he has HL7 specification and if he can share it.


TomFennelly wrote:
  
Hmmm... if I follow the thread... no, nothing has been done on it.  
Classic case of the squeaky wheel(s) getting the oil and this wheel 
wasn't squeaky enough :)

We're interested in doing something for HL7 if someone is able to share 
the specs with us.

T.


cozyroc wrote:
    
Tom,

I wanted to find out what has happened since? I haven't found any work
items
published in the tracking system and the discussion hasn't been active
for
more than a year.


      
    

-----

--
Regards,

Ivan Peev

http://www.cozyroc.com/blog  http://feeds.feedburner.com/CozyRocBlogs.1.gif  

  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

cozyroc
Tom,

You are correct. I don't like the push-back behavior too much either. The way the EDI parser is implemented so far is elegant. I guess I'm having the straw-man approach to the problem, trying to workaround the issue somehow. The approach I have described is not going to require changes down the chain in our current implementation. We depend on the fact that fields doesn't loop like the segments. If the fields start behaving like the segments, we have to re-design the component that depends on the parser. My thoughts about the situation is that the proposal on hand doesn't change the parser behavior to the outside world too much. Any re-definition of the current EDI "field" concept, will have cascading effect on the dependent components as well. So this point is worth considering.

Have you seen these links:

http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_adapters.doc/doc/healthcare/hl7mst73.htm

http://155.230.149.102/result/Paper/1-1/%EC%9D%B4%EC%83%81%EB%AF%BC_%EB%85%BC%EB%AC%B8%EA%B2%8C%EC%9E%AC%205.pdf

I have found them by searching for "hl7 field repeat"

TomFennelly wrote
Hi Ivan.

Can we get more info on this?  How is this described within the HL7
specs?  Is this a formal construct?

Taking your example of:

    A|B|C~D~E

On an application level, what is not covered if the parser generates the
following for the above segment:

    <theseg>
        <name>B</name>
        <stuff>
            <s1>C</s1>
            <s2>D</s2>
            <s3>E</s3>
        </stuff>
    <theseg>

Functionally.... is it not possible to read that structure in the same way?

I think the main thing is that we need more info here.  I'm a bit wary
of adding reader push-back type behavior in the parser.  I think that
might be a slippery slope :)

T.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

John DeStefano-3
In reply to this post by Tom Fennelly

Hi,


We are currently using smooks to parse some "simple" HL7 messages where we are sure of the structure up front. The biggest issue we have for general parsing is the one in this thread. I'd like to do more with smooks as we are using the JBoss ESB for our current project which includes a lot of HL7 parsing. I'd certainly participate in further discussion around this topic.


Thx

>>> Tom Fennelly <[hidden email]> 3/8/2010 3:25 PM >>>
Hmmm... if I follow the thread... no, nothing has been done on it. 
Classic case of the squeaky wheel(s) getting the oil and this wheel
wasn't squeaky enough :)

We're interested in doing something for HL7 if someone is able to share
the specs with us.

T.


cozyroc wrote:


> Tom,
>
> I wanted to find out what has happened since? I haven't found any work items
> published in the tracking system and the discussion hasn't been active for
> more than a year.
>
>
> TomFennelly wrote:
>  
>> Bård Langöy wrote:
>>    
>>> Hi,
>>>
>>> Tom, you wrote:
>>> Yeah... but how would you know which field/component/ etc is which since
>>> they are not "named"?  At the moment we only know which field/etc we're
>>> dealing with based on it's fixed position.  It's fixed because there's a
>>> fixed cardinality  i.e. min/max = 1.
>>>
>>> Bård: Couldn't we simply remember the last field/component/sub-component
>>> (FCS) in the EDIParser and in the case when a recursive-delimiter shows
>>> up, the saved FCS is used and not the next in line. I must admit I
>>> haven't checked if it is possible yet, but it feels like that would be
>>> the easiest way to configure the edimap. I could take a look at it and
>>> see if it is possible.
>>>  
>>>      
>> If I understand you, I don't think that would work Bard.  It needs to be
>> able to support cardinality on the split-field.  The way I think about
>> it is re breaking it down from a segment.  The segment is the only thing
>> that's actually named.  Everything else is identified by position only
>> (the FCSs).  This is why the parser doesn't currently support
>> cardinality on the FCSs.
>>
>> So at the moment it works by:
>>
>>    1. Buffer the next segment.
>>    2. Split out the fields using the field delimiter.  This also gives
>>       access to the field id/name.
>>    3. Check is the segment expected relative to the current segment.
>>    4. Start processing each field based on the segment spec and the
>>       field positions.
>>    5. For each field, split out the components using the component
>>       delimiter.  Process each component based on the field spec and the
>>       component positions.
>>
>> So at the moment, processing of the FCSs is totally based on position. 
>> This effectively means you can't support cardinality at these levels
>> without introducing something more.
>>
>> As I see it, the easiest (least intrusive) way of supporting what John
>> needs is to introduce a little twist at the field processing level (at
>> #5 above):
>>
>>    1. Buffer the next segment.
>>    2. Split out the fields using the field delimiter.  This also gives
>>       access to the field id/name.
>>    3. Check is the segment expected relative to the current segment.
>>    4. Start processing each field based on the segment spec and the
>>       field positions.
>>    5. /For each field, check is it a "split-field".  If it is, we split
>>       the field based on the split field delimiter (e.g. the '~' char)./
>>    6. /Check the split-field cardinality constraints i.e. validate the
>>       min/max split-fields.
>>       /
>>    7. /For each split-field, split out the components using the
>>       component delimiter.  Process each component based on the field
>>       spec and the component positions etc etc/
>>
>> I didn't mention where the split-field delimiter comes from, but that's
>> a no-brainer.  I think we should support a split-field-delimiter in the
>> <delimiters> definition and allow that to be overridden in the
>> split-field def through ref to a field that specifies the delimiter, or
>> by specifying the delimiter explicitly.  As John says, HL7 may not need
>> all of this, but I still think it would be good to add it.
>>
>> Am I missing something?
>>
>> T.
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SV: SV: HL7 parsing problem

Tom Fennelly
OK guys.... lets do something to fix this :)

John DeStefano wrote:

>
> Hi,
>
>
> We are currently using smooks to parse some "simple" HL7 messages
> where we are sure of the structure up front. The biggest issue we have
> for general parsing is the one in this thread. I'd like to do more
> with smooks as we are using the JBoss ESB for our current project
> which includes a lot of HL7 parsing. I'd certainly participate in
> further discussion around this topic.
>
>
> Thx
>
> >>> Tom Fennelly <[hidden email]> 3/8/2010 3:25 PM >>>
> Hmmm... if I follow the thread... no, nothing has been done on it.
> Classic case of the squeaky wheel(s) getting the oil and this wheel
> wasn't squeaky enough :)
>
> We're interested in doing something for HL7 if someone is able to share
> the specs with us.
>
> T.
>
>
> cozyroc wrote:
> > Tom,
> >
> > I wanted to find out what has happened since? I haven't found any
> work items
> > published in the tracking system and the discussion hasn't been
> active for
> > more than a year.
> >
> >
> > TomFennelly wrote:
> >  
> >> Bård Langöy wrote:
> >>    
> >>> Hi,
> >>>
> >>> Tom, you wrote:
> >>> Yeah... but how would you know which field/component/ etc is which
> since
> >>> they are not "named"?  At the moment we only know which field/etc
> we're
> >>> dealing with based on it's fixed position.  It's fixed because
> there's a
> >>> fixed cardinality  i.e. min/max = 1.
> >>>
> >>> Bård: Couldn't we simply remember the last
> field/component/sub-component
> >>> (FCS) in the EDIParser and in the case when a recursive-delimiter
> shows
> >>> up, the saved FCS is used and not the next in line. I must admit I
> >>> haven't checked if it is possible yet, but it feels like that would be
> >>> the easiest way to configure the edimap. I could take a look at it and
> >>> see if it is possible.
> >>>  
> >>>      
> >> If I understand you, I don't think that would work Bard.  It needs
> to be
> >> able to support cardinality on the split-field.  The way I think about
> >> it is re breaking it down from a segment.  The segment is the only
> thing
> >> that's actually named.  Everything else is identified by position only
> >> (the FCSs).  This is why the parser doesn't currently support
> >> cardinality on the FCSs.
> >>
> >> So at the moment it works by:
> >>
> >>    1. Buffer the next segment.
> >>    2. Split out the fields using the field delimiter.  This also gives
> >>       access to the field id/name.
> >>    3. Check is the segment expected relative to the current segment.
> >>    4. Start processing each field based on the segment spec and the
> >>       field positions.
> >>    5. For each field, split out the components using the component
> >>       delimiter.  Process each component based on the field spec
> and the
> >>       component positions.
> >>
> >> So at the moment, processing of the FCSs is totally based on position.
> >> This effectively means you can't support cardinality at these levels
> >> without introducing something more.
> >>
> >> As I see it, the easiest (least intrusive) way of supporting what John
> >> needs is to introduce a little twist at the field processing level (at
> >> #5 above):
> >>
> >>    1. Buffer the next segment.
> >>    2. Split out the fields using the field delimiter.  This also gives
> >>       access to the field id/name.
> >>    3. Check is the segment expected relative to the current segment.
> >>    4. Start processing each field based on the segment spec and the
> >>       field positions.
> >>    5. /For each field, check is it a "split-field".  If it is, we split
> >>       the field based on the split field delimiter (e.g. the '~'
> char)./
> >>    6. /Check the split-field cardinality constraints i.e. validate the
> >>       min/max split-fields.
> >>       /
> >>    7. /For each split-field, split out the components using the
> >>       component delimiter.  Process each component based on the field
> >>       spec and the component positions etc etc/
> >>
> >> I didn't mention where the split-field delimiter comes from, but that's
> >> a no-brainer.  I think we should support a split-field-delimiter in the
> >> <delimiters> definition and allow that to be overridden in the
> >> split-field def through ref to a field that specifies the delimiter, or
> >> by specifying the delimiter explicitly.  As John says, HL7 may not need
> >> all of this, but I still think it would be good to add it.
> >>
> >> Am I missing something?
> >>
> >> T.
> >>
> >>
> >>    
> >
> >  
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


123
Loading...