Clovertech

HL7 Variants – converging philosophies

› Clovertech Forums › Cloverleaf › HL7 Variants – converging philosophies

org1 or org2 ?

Variant Management

You must be logged in to participate.
  • #1 Org1 - Only when necessary due to struture
  • #2 Org2 - at the Application level (1 for each sending/receiving app)
  • #3 Neither - Describe option in response
  • Creator
    Topic
  • August 25, 2020 at 2:00 pm #117720
    Bob Schmid
    Participant

      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

       

       

       

    • Creator
      Topic
    Viewing 3 reply threads
    • Author
      Replies
      • August 25, 2020 at 2:20 pm #117722
        Jim Kosloskey
        Participant

          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.

        • August 25, 2020 at 2:48 pm #117723
          Jeff Dawson
          Participant

            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.

            • August 25, 2020 at 3:42 pm #117724
              Jim Kosloskey
              Participant

                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.

            • August 25, 2020 at 3:46 pm #117725
              Vince Angulo
              Participant

                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.

              • September 5, 2020 at 9:45 pm #117800
                Jim Kosloskey
                Participant

                  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
              Viewing 3 reply threads
              • You must be logged in to reply to this topic.