HL7 Segment Def

[Bob Schmid]

We are dealing with Mckesson’s Awarix/HEV product which sends out Room cleaning A20’s with a home grown segment of ZAX….their ZAX field 1 contains a “record type”…which dictates the format of the segment…..I have never seen the case of segment layout changing based on a segment record type…….

😡

other than a specific tcl code to handle the different formats…..my question is more general;

Is this “proper HL7” to define a segment with different layouts ? It effectively destroys the ability, to my knowledge, to configure this within the current HL7 Cloverleaf configurator. running 5.6..it almost conforms to the “MASK” concept within FRL’s or VRL records.

Topic

[Jim Kosloskey]

Robert,

Give us a description of what you mean by the format changing.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jim Kosloskey]

Robert,

Depending on your answer, I think this can be done in an Xlate and a variant definition.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Bob Schmid]

ZAX Segment Types

Below is a list of the various types of ZAX segment, as determined by the contents of ZAX.1. The fields

contained in each type of ZAX segment are described in further detail in the next section.

PATIENT 4.3 Provides information about the

current status of a patient.

BED 4.1.2 Provides information about the

current status of a bed.

HL7 4.3 Provides information about the

incoming HL7 message

Example of PATIENT layout:

ZAX.1 4.3 Always PATIENT

ZAX.2 4.3 Medical record number

ZAX.3 4.3 Unit assignment (will always be

consistent with PV1.3)

ZAX.4 4.3 Discharge status: one of none,

pending, scheduled, or stepdown

ZAX.5 4.3 If on code alert: time went on code

alert in the form 20031215163000

ZAX.6 4.3 Acuity: 0 for none/unknown,

otherwise 1, 2, …

ZAX.7 4.3 Isolation type identifier (if patient

is on isolation)

ZAX.10 4.3 If (and only if) patient has a bed

request: time request created in

the form 20031215163000

ZAX.11 4.3 If (and only if) patient has a

bed request: bed request type

identifier(s) (this field may be

repeated)

ZAX.12 4.3 If (and only if) patient has

a bed reservation: time

reservation created in the form

20031215163000

ZAX.13 4.3 If (and only if) patient has a bed

reservation: reserved bed

ZAX.14 4.3 If (and only if) patient has a bed

reservation: reserved unit

ZAX.15 4.3 If (and only if) patient has

a transport request: time

request created in the form

20031215163000

ZAX.16 4.3 If (and only if) patient has a

transport request: transport

destination identifier

…different layout for BED type and different layout for HL7 type too…

[Jim Kosloskey]

Robert,

Then for BED  and HL7 are there the same number of fields or are there different  number of fields?

Are all of the fields the same Data Type? If not is the data actually sensitive to the Data Type?

Do the ZAX segments (PATIENT BED HL7) always present in that order?

What I am thinking is:

Make your variant for the ZAX segment be repeating and make the number of fields the largest number of the three types. Treat each field as a TX or ST Data Type. Name your field names generically (like field_1, field_2, etc.). In the Xlate iterate over the ZAX segments. Inside the Iterate, do an IF to check to see what segment you have based on ZAX-1 (or whatever field it is) in case they are not always in the same order or in case some could be missing. For each IF do what you want with each relative field (field_1, field_2, etc.) based on your known needs for that particular ZAX segment.

Based on the information provided thus far, I don’t see this not being able to be completed in an Xlate with creative variant definition.

Now as to your question regarding is this legal in HL/7?

I have not fully researched this but unfortunately most of the HL/7 rules (the little that are followed) are pretty well suspended for Z segments and User fields.

When I see Z segments I immediately assume the vendor either does not have a toolset that will allow exploitation of HL/7 in it’s entirety (believe it or not some MAJOR vendors cannot handle various repetitions like field repetitions) OR the vendor does not understand HL/7.

In either case the vendor probably does not hesitate to boast they are HL/7 ‘compliant’ for sales purposes.

McKesson should be ashamed of themselves to publish this level of junk. Especially since they are a reseller of Cloverleaf(R) and thus have an excellent toolset at their disposal.

Sounds to me like they purchased a system which did not have HL/7 capability and then rather than spend the necessary dollars to do a good job they just slapped something together.

Have fun!![/list]

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Bob Schmid]

Follow and concur!

🙄 Thanks James!

[Author]

Replies