Provide support for HL7 v.2.x support for SV and Test.
If anyone has an HL7 payload, please share.
So, I think this is a great enhancement!
I ran into some customer in LATAM (Amil) asking if we can virtualize medical equipment using TCP/HL7 and HTTP/HL7.
Recently I have talked with Hospital University of Chicago and Cerner about this type of virtualization.
I know that our Services just delivered a project at CHI, and I talked with Ball, Courtney E <Courtney.Ball@ca.com> about it.
I think it is a good idea to reach out services to see if we can get HL7 payload examples and probably their custom DPH to check if we can reuse it and add to the product!
That's awesome! Chris Chris_Kraus, can you add this HL7 extension to the items we want to publish on the community?
There are many issues about sharing payload examples and payload examples are of little use unless you fully understand that a response will be generated in some instances and will be returned on a different port. HL7 is not a rigid standard and vendors often use it as they want to. We are still trying to get enough knowledge about how to handle, the responses and to build and send an appropriate response. We are a long way from having a useful tool in our environment.
I have a lot of experience with HL7. One of my previous jobs was in the medical data integration space, and as part of that I wrote an HL7 system from scratch. JCHatCHI is kind of downplaying how loose the HL7 "standard" really is. For each vendor we basically had to start from scratch and write custom data mappings. No two vendors assigned the same semantic meanings to the same HL7 fields.
There are a couple of common fields that are always the same, like a message ID and message timestamp. But for the rest of them the best we could do in the general case would be to extract them into properties with names like 'PID.5.1' or 'SCH.11.4', which basically just describe their positions inside a v2.7.x delimited HL7 message. Those examples typically map to 'patient last name' and 'appointment scheduled time', but not always. The problem is similar to Copybook, where the customer would have to provide us some kind of data definition we could use to assign semantic meaning to each HL7 field. However, unlike Copybook, there is no standard format for an HL7 data definition.
Data mappings aside, there is a lot of variation to how HL7 is exchanged in general. There's TCP, TCP on multiple ports, File-based, HTTP, and some other stuff so weird I can't even describe it. Sometimes there's an ACK acknowledgement message, sometimes there isn't. Sometimes messages are sent in batches. Sometimes ACKs are sent back in batches. Some HL7 messages are informational while others are queries requiring a response, and that response can be correlated in a number of ways.
Even the format itself is variable. Sometimes multiple HL7 messages are separated by special separator characters, sometimes they're just mashed together. Lots of vendors play fast and loose with newlines. Usually reading HL7 is not a problem, but generating it in the format that the other side expects can be.
I'm not trying to be discouraging, but trying to do "one size fits all" with HL7 is very difficult. However, there is a huge market out there for it, in addition to other similar protocols in the space like X12 and EDIFACT.
Thanks for sharing, I though HL7 was complex and loose, but now I am sure.
I think we could at least have something build-in on the product so we don't need to start from scratch. I not sure how, but at least with some mapping suggestions collected by the field for each different version (2.x) and then we can validate and tweak during implementation.
I am not sure if the Healthcare industry is adopting the newer 3.0 version (xml based) , any thoughts ?
Yes, we can build out a baseline field mapping based on the HL7 spec. But that's a lot of work, even if we stick to just a handful of the dozens and dozens of possible HL7 messages. We could also opt to utilize one of many free or not so free HL7 packages out there, but I think we'll quickly run into the same problem we did with web services and Apache Axis: The available packages are not flexible enough to be used as testing tools.
Hl7 3.0 was released almost ten years ago. If my experience with healthcare IT is any indicator then we might see some noticeable adoption in another ten years.
After paying CA to fix the presentation of HL7 in a form that is generally used by those dealing with interface development and having to communicate with multiple vendors we have been able to do work with HL7; however, it uncovered a big issue in that the Response to an HL7 message is typically an ACK and in some case, the ORM/ORU pairing, there are at least 2 responses, the ACK for the received ORM and then one or more ORUs. This poses a problem as the virtual service is a server and not a client. Ashutosh Satyam solved that for us as well as resolving the presentation of the HL7 data in a readible form. We can now receive a message, ACK the message, and then send 1 or more responses to different IP addresses and ports, with a prescribed delay, which is necessary. We are experiencing a problem in that the code that provides the client functionality does no appear to work when attempting to use multiple threads, also required to handle the volume of messages that would be generated with automated testing and performance/load testing.
We have asked CA to productize these capabilities; first because we do not want to be stuck at our current version because the code fails with the next release, and secondly, because we cannot see SV being used in our Healthcare Provider space without them. We have also been using a technique that allows us to accept the large variences in message appearance (even from a single application). We feel that we have the ORM/ORU issue defined and have a way to deal with it and we are now looking at more complex message interactions with a downstream application. Finding the right staff is vital and having some one to identify use cases and analyze the messages so that common data is identified and what the links are between different message responses and the original message.
Suffice it to say that it has been an interesting journey and we have just begun. Look for more technical information from Jude Baffico. If you are not following her and you are interested in HL7, you should be.
Retrieving data ...