HL7 Variants – converging philosophies

[Bob Schmid]

So…after running CLoverleaf for approx. 20 years….we have merged with another large Healthcare organization also using “The leaf”! 🙂

 

Org1 – use the same HL7 variant (v1) for Inbound as outbound unless structurally different needs.

– use v1 across the platform  if possible.

–  Create new variant only if inbound or outbound necessitates due to structure

– and cant be accommodated (ex optinal) in original v1.

Org2 – use different variant for each application even if structure is shared/equal between apps. (ie A01 created, parsed, received the same way)

**********************

Org1 – out of necessity create (structural differences between two apps)

Org2 – flexibility?, separation.. (create new variant for each app even if same with forward looking / separation is good in mind.

 

Any thoughts or differences in how you guys manage HL7 ?

Thanks

Bob

 

 

 

Topic

[Jim Kosloskey]

My preference has always been #2 and that is the way I voted (each application has its own variant even if it does not differ from the standard and matches another system – with adaptations which are specific to the application).

However, either method can definitely work as evidenced by the 2 organizations.

The question now is if one methodology is to be adopted do you attempt to retrofit to fit the single methodology? That could be very time consuming and challenging.

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

[Jeff Dawson]

I believe we have instances of both ORG1 and ORG2 but over the years it seems we’ve gravitated towards ORG2 similar reasons to what Jim responded with.  Now that we are close to finishing our migration to Epic it could spark a conversation again of having one inbound Variant for Epic per data type since that feed would be the same on the inbound side then creating an individual system variant for the outbound side if it deems necessary.  I know currently when we go through an Epic upgrade and if/when a new custom Z segment is added on say the ADT feed we have to research what variants would need to be updated.   From a support standpoint it would be nice to have a singular inbound variant in the master site for a one stop shop, either way it’s nice to have the flexibility.  Back when we were doing a great lakes user group, I was surprised at how many shops were doing just tcl, want to say it was 50/50 in the room.  I’m not against that but it definitely can put a strain on other teammates who may not be as comfortable vs GUI programming.

[Jim Kosloskey]

I guess I should make sure of what I prefer. I prefer a given system (say EPIC) have one variant for ALL Message/Event Types (sometimes that is not possible due to Vendor issues) but as few variants as possible.

Before I was asked to leave MDACC I advised  the Integration team working on the EPIC thing to construct as few variants as possible. They had some issue understanding how to and accept use one variant for EPIC for both IB and OB. So they constructed 2 variants. To this day I believe one variant for both IB and OB for most systems (including EPIC) is possible. BUT one needs to get the appropriate information from the vendor to completely understand the potential message structures rather than just looking at sample messages.

The other thing I had them do was to construct the variant at 2.7 since that is eventually where EPIC would need to arrive. That way when EPIC deployed in a new release segments/groups not previously observed in a previous release, the variant would be ready (although the Xlates would need to change to actually reference the data). Of course there is no way to avoid when the vendors decide to deploy Z segments rather than follow the standard – no choice then, variant must change.

Those variants existed in the Master Site and were required to be used by every reference to EPIC.

Although I was not there for the next EPIC upgrade, I understand there were no variant surprises as EPIC deployed previously unused variant elements defined at a higher level that 2.3.1 (which is what EPIC had advised).

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

[Vince Angulo]

I put ORG1 which is how we’ve run for the last 15 years on Cloverleaf.  As we were mostly one keystone app, Cerner, it served us well.  But now we have Cerner (EMR and Anciliaries) and Epic (Reg and A/R), and will be adding a lot more Epic EDI in the next few years, ORG2 may make more sense.

[Jim Kosloskey]

ONLY 7 people have an opinion? Really?? Come on folks – what are your thoughts?

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

[Author]

Replies