[Chad Flodman]

James – sorry saw my missing word, my post/inquiry was in reference to translation tables (not translations i.e. xlates).  Xlates(translations) will of course be all in Cloverleaf for us.

Thanks for catching that.

[Chad Flodman]

John – We are just ahead of your Epic timeline here.  Our Bridges team was just certified this year (2016).  We are two weeks from our interface direction setting meetings.  Bridges certification alone is a 2-day class in Madison, one test, one project.  Do read the material for the course prior to class it will help immensely.  Those with prior interfaces, HL7, or programming experience should have no problems with certification.  Epic starts at a foundation level and moves on from there.

I saw an interesting post from Tony Benitz.  Tony I would be curious to your opinion on your site

[Chad Flodman]

Bob – this will do your static routing ADT_A04_ADT_A01 for a 2.5.1 message or wildcard ADT.A04.ADT.* – or variations thereof.

Basically, in wildcard routing;

The . is regexp for “any single character” in the used encoding set typically ANSI or UTF-8.

The .* is regexp for “any character from here i.e. multiple characters”

Hope that helps you out…

[Chad Flodman]

Mike – we’re still on v5.8r5, so some things are going to be a bit differnet for us; like where to put the Tcl proc, how the protocol / thread are configured, etc….  On our version this is inlcuded in an HTTP protocol thread in the queryTPS proc and we have the ssl license.  Here in California for our Public Health Agency (PHA) connection, I had a wsdl to follow for the SOAP envelope and I just used Tcl to wrap it around the hl7 message like below.  The variable $inMsg is the HL7 VXU message coming into the engine.

Code:

….
# Apply SOAP-ENV to the HL7 Message
set soapenv {USERNAMEPASSWORDCAIR}
….

Then set your outbound message handle to the variable soapenv, which has the SOAP enveloped HL7 message.  Similar to;

Code:

…
msgset $mh $soapenv
lappend dispList “CONTINUE $mh”

This is all sent over TCP ssl secured connection.  It may not be very elegant, but it’s been doing the job for us for now.  One thing to watch for is most like the “ACK/NAK” will be returned to you in XML (SOAP enveloped), so you’ll most likely need a proc to deal with the reply unless you ignore them.  I just stipped out the HL7 from the XML then ran it through the regular cl_check_ack that we use.

[Chad Flodman]

No we’re on McKesson (HLAB) Lab product.  We

[Chad Flodman]

2.7 is out already and I certified on that version.

Now the “is it in use question” – that gets more fun.  Vendors typically do not stay up to date with standards, especially HL7 versions.

It’s one of the good things about all the ARRA, MU and regulation changes going into effect.   At least it’s forcing antiquated vendor HL7 interfaces – typically v2.2 or 2.3 – to at least get up to v2.5.1 for lab report and some others.

If you find a good way to pressure/nudge your vendor into getting to a more acceptable version, let me know.  I’ve gone so far as to tell our upper management when considering new software / vendors, if the HL7 version is not 2.5.1 or higher, toss them out of the list regardless of other factors.  Unfortunately, I doubt that this will get routinely followed.

The crux of the issue becomes that all users / departments want what higher HL7 versions can provide and have defined, but we are at the mercy of our vendors most of the time.

[Chad Flodman]

We too are definitely going thru Cloverleaf-5.8Rev5 for MU2, ELR reporting and Immunizations, Syndromic Surveillance.  The interpretation here is as long as Cloverleaf is in compliance with the v2.5.1 standard we can make the necessary adjustments to be conformant at the federal / state levels.  We are not passing CDA-R2 (XML) type data thru Cloverleaf at this point, this and DirectExchange are going directly from our EHR.

In this way as an organization we are confident we will meet not only the federal level requirements, but our state level which further constrains the profile for ELR.  Ultimately the organization will be penalized not the vendor if submission is not up to spec, so we’d rather have the “last say” if you will.

In HL7 v2.5.1 there is an SFT segment that should be valued for any application/process/software that the message is passing thru that serves as a notice to any endpoint how the data came to them i.e. who/what could have altered the information.  Although an optional segment, in my opinion this segment is of significant value.  This shows the data originated from a certified system, which I would argue, addresses the SunQuest concerns and meets the requirements.  Also, let’s face it point-to-point interfaces are extremely archaic and only warranted in very few situations assuming you have integration staff with experience.

[Chad Flodman]

Yes, ours is the HMM Meds Manager that I’m describing.  We are in “talks” to move to the McKesson Paragon platform.  Which is part of their “Better Health” initiative to retire their HORIZON application line in favor of Paragon.

So we’ll be chaning our set-up with-in the next 1-2 years in relation to Pharmacy.

[Chad Flodman]

I have setup interfaces between HMM (McKesson Rx) and their “automation” product line of AcuDose (Med cabinets) – ConnectRx (The interface application for the whole automation line), PacMed, RobotRx (Pharmacy Robot).

Also, I believe the HMM application is being retired as a product and being replaced by the McKesson Paragon product with Rx application included in this line.

Overall it’s pretty straight forward, and basic messages – ADT, RGV, RDE, OMP, RAS, DFT etc….  There’s one custom message for pocket loads/charging purposes from the AcuDose cabinet line.

Also, make sure your MPI (EMPI) values (PID-2, PID3) for your environment are correctly setup and your structure is followed at the begining of the install of these products – especially if you’re multi-facility, multi-entity.  You may even have to push back on some of the installers to get them to do this correctly, but it’s critical to on-going support of the applicaitons and ease of interface support and application interoperability from install forward.

Historically, the vendor and the Rx product line don’t seem to like to run their interfaces throuh an engine.  They don’t say this, but you get the feeling they’d really like these to be point-to-point interfaces from 20+ years ago.  I’d strongly recommed that you use your engine as I can’t count the number of flawed messages, segement and fields I’ve had to adjust in this product line.

[Chad Flodman]

Here we’re using the HPF outbound documents feed (via HMS) for our medical transcriptions to multiple in house system i.e. clinicals (HCI), CNExT (CA Registry), RelayHealth (RDS)….  These are via MDM messages we convert to ORUs for the receiving systems.

The messaging setup in the engine was easy.  It was not an easy thing to setup on HPF and get stable.  Once we got all the HPF outbound issues resolved though it’s working quite well.

If you’re looking to accomplish something similar, I’d be happy to review with you.

[Chad Flodman]

Jim – yes same thing.

[Chad Flodman]

Jerry – Thanks for the .ecd info, I’ll focus in on the DB error I was getting and post if I can track anything down on that track.

[Chad Flodman]

I’ve just started to run into this on one of our processess testing our upgrade environment to v5.8R5.

[Chad Flodman]

Depending on what you’re doing check out the msiAttach options in the documentation as well…

[Chad Flodman]

Jim – I was just looking into IHE options over the weekend.  I too would be interested if anyone is using the Cloverleaf IHE addons.  Looking at possible connection to an HIE via this method in the upcoming months.

[Author]

Replies