[Jason Gross]

It doesn’t go through a firewall. I’ll escalate it up again through our Cloverleaf admins to see if they have exhausted all options.

[Jason Gross]

Thanks guys, it happens to probably about 15 of us and I think it’s been looked into before. I was just curious if it’s just isolated to different configurations, volumes, etc. It seems like our issues are probably very similar to Diana’s issues. I don’t think anybody wants to pursue it further but I was hoping maybe somebody had a workaround that was more successful than anything I’ve had.

The back-end will always work, but we don’t have access to that in production yet and I prefer using the GUI for simplicity.

Thanks!

[Jason Gross]

Hi Mary–I guess we could just message each other:)

I have not found a way to speed it up, I think it just takes that long to process the items individually. In a way it makes sense as if we had to replay 5000 normal hl7 messages it would also take that long to process individually through the xlates, update the file, etc.

[Jason Gross]

Thanks a lot guys will continue to look at it.

I recognize there isn’t a header there, but they said they don’t need it. The VRL setup does have all the fields identified. The inbound is read immediately but the xlate processing and output is the slow part. I’ve pasted the file to the file system and it’s almost immediate so it’s not I/O for the file share.

I’m not great with all of this, we typically handle HL7 messages with xlates and tcl procs using TCP/IP, not VRLs and FTP. I’m not following how to account for the characters. I understand there’s a CR/LF at the end of each line, but how do you account for or do anything with that since you can’t see it? Since what I have works in 20 minutes (which isn’t a problem) we’ll go ahead with it as it is for now.

[Jason Gross]

Thanks for the suggestions guys.

I changed it to 1000 but that didn’t help. In watching it now, it’s closer to 20 minutes to process it. It’s shouldn’t be any kind of a load on our server but I’ll move it to our prod server that handles millions of messages/day and see if it processes faster.

An example of the first few lines are below. Message 1 below is what I get in the xlate testing tool when I change it to “single” or “EOF”. I’m not sure why it keeps thinking the file ends after the first two fields on the first line of data.

emp_num,badge_num,credit_limit,emp_name,allow_charge

“1685434”,1024470,293.00,”Flinstone, Fred”,Y,Y

“1976741”,1152297,297.80,”Jetson, Judy”,Y,Y

“1977402”,1118059,300.00,”Elroy, Lawrence”,Y,Y

MESSAGE 1

        emp_num: ch >emp_num<

      badge_num: ch >badge_num<

   credit_limit: ch >credit_limit<

       emp_name: ch >emp_name<

   allow_charge: ch >allow_charge”168584″<

allow_charge_two: ch >101124470<

[Jason Gross]

Read interval: 5

Scan interval: 30

Max messages: 2000000

Same for outbound but I assume those can be wiped out there.

[Jason Gross]

Thanks for the reply, I’ll have to share this with some colleagues to see if it’s possible.

[Jason Gross]

Thanks for pointing me in that direction! I removed the xmlns=”” from the schema and it compiled!

<xs:schema id="levelone" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema&#8221; xmlns:msdata=”urn:schemas-microsoft-com:xml-msdata”>[/b]

[Jason Gross]

I really appreciate your time in looking at it. I went to a site that could automatically generate the .xsd and it also created a schema that generated the same error message so it seems like the .xsd is not the problem. I will pursue other avenues that may include Cloverleaf support. Thanks!

[Author]

Replies