Has anyone done any type of HL7 interface programming with RS or Xojo?
I have. A Windows service that interfaces a contractor developed web app to a dental package.
Nice. I’m interested in how you went about parsing the message. Are you doing any transforms to the message at all.
I did a bunch of research on this about two months ago. Unfortunately, I’m on the road and have none of that available. If you don’t get any good results send me a private email and I’ll try to find some of it.
Thanks, Bob. I’ve done alot of HL7 interfaces using RS and Xojo. Since I’m an HL7 Developer/Analyst, I’m interested in the different ways people have done this.
Ah, well then I should be talking to you rather than the other way around!
I have a project that will need to use the HL7 interface. The only library I’ve really found is Chameleon but I’ve not even downloaded it yet (as I have a list a mile long for the rest of the project).
Sorry about the multiple private conversations. I kept getting an error saying it couldn’t save the message, but apparently it did
I was in the medical branch or about 10 years, we used Chameleon back then to map packages, mostly because when starting it then we had limited in house knowledge of HL7. If I had to do it again then I would never go that way, would probably attempt to create a parser. Whats right or you may also depend on your knowledge of HL7 and its syntaxes, and differences between different versions, and most of all the scale o what you need ask n how many package types and how complex they are. We only had to dead with like 8 send packages and 2 receive ones.
Part of our problem is that the client really hasn’t defined what has to be done. HL7 is a vague ‘want’ with nothing concrete other than wanting to integrate into ‘medical devices’.
Bob, let me know if you need any assistance.
I started with no knowledge of HL7 so I looked around for existing software to do the job. I settled on doing it myself with an app vs trying to use a third party package. Part of my decision was based on the fact that I would only have to support 4 message types. ADT A31, A04, A08 and DFT P03.
I built a class that handles parsing incoming messages, storing and pulling the data and building the outgoing messages. Since HL7 is a nicely formatted array of string arrays I simply strip the wrapper off and split the message into an array. I can then run through the array and parse the segments as needed.
As for transforms there are a couple things I have to translate between the two. One I handle in the app, two were done in translation tables on the other end and another I was able to add a field to a table in the custom DB. I would actually prefer to use the translation table option whenever possible since that’s easier to support then changing and recompiling the service.
Nice Job Zane. I would love to see your class that does this, but of course, if you do not want to share it, I totally understand. I basically did the same thing but didn’t use classes and I’ve been thinking about converting mine to use classes.
Well, my code is really messy and embarrassing. And I’m in the middle of extending it to talk to the main EMR software and to a watchdog service so it’s even messier.
I am working to clean it up while I’m expanding it. Maybe I can share it when I’m done.
Was there any news from anyone related with Xojo and HL7.
Anyone had developed or found any third party class available for an easy implementation of HL7 with XOjo ?
I will appreciate any help
Everything about HL7 is always vague!!! I worked a lot with it many many years ago and I don’t think any single was ever able to say what they wanted they just wanted something HL7.
I am guessing the newer XML based HL7 standard still has not caught on ?
I wrote my own HL7 interface for my product after reviewing most of the third party systems. They all are very expensive. Most of my client interfaces are custom, i.e., we say “send us a message of what you send” and “what information do you want to see from us”. I modify my base system then to comply with their system. Been working for years without a hitch. There are many ways of acquiring their data and ways of sending to them; it usually depends on the customers needs.
I deliberately didn’t write a generic do-everything system because of the size and complexity of HL7. I identified the subset of segment/component/field messages needed for each client and then used my abstract message builder to do just that system.
I’m not working in FileMaker anymore professionally so will be porting the code to Xojo sometime in Q1/Q2 of 2017. Guess I’ll find out if there’s any hitches with that then.
You might consider using Mirth. It is an open source translator that you can run as a CRON in Linux and translate incoming HL7 into a SQL DB or vice versa. From there you can use Xojo to do the post processing. It might also be available for Windows but I am not sure. I have used it before and it seemed to work well.
One problem I had was data came from two sources and they interpreted the use of HL7 codes differently in their translation from their clinical system into the HL7 data stream so I ended up with two maps. We might have had the two sources modify their systems but since “the customer is always right” we just made custom maps. My experience with other EDI data streams had the same problem. Usually the data set definitions are very broad to accommodate all kinds of variations in the data and sometimes the source applies their own subtle differences. The standard map might be 98% accurate but you cannot ignore the other 2%.
Well, I had a project with HL7, too.
But that was just Socket/SerialPort an calculating the right checksum for the data packages.
Not a big problem. But depends on what you have to do.
My apps are EMR for pediatricians and gynecologists.
I have to implement some messages of the HL7 CDA R2 in order to be HL7 compliance and could exchange some messages with other systems.
Probably in the future I could need to implement some more mesages to interact with some medical devices in order to exchange reports and images.
As Mark suggested Mirth is the most common way to translate messages of different HL7 versions and also to create communication channels betwen systems/devices.
I am trying to find some easiest tool to do that as Mirth required some practice and very specific knowledge to be well implemented.
I looked at Mirth very early one and played with it for a while, also Iguana. It is not a friendly system but appears to have great potential for those with the skills and time to master it. Of course, you can pay to have the backend company do stuff for you.
We found that almost no one adheres to the standard. Writing a strict standards based module could end up being frustrating. We opted to customize each one since we’re not selling millions (thousands?..uh hundreds?) and we have the time to do so.
My pet project is a module that will take their messages, parse it, and auto-create everything on our side. Not impossible at all, just time intensive. So far it’s been a hands-on approach.