Clover Leaf Practical Guide?

Lester,

I am not aware of any ‘Guide’.

It probably would be a good idea to become familiar with the most common message structures you will be encountering on a day by day basis (if healthcare probably HL/7, FRL , and VRL).

For the standards based message structures getting your hands on the standard’s guide(s) would be very helpful.

There is also some education for some of the standards available from various vendors.

As for Cloverleaf(R) itself, if you have successfully been through Level 1 and Level 2 then theoretically you have all of the basis you need to begin work (using the documentation provided as well).

If you have any prior experience doing integrations (with or without the use of an Integration Engine), then the same principals that you learned doing those apply here.

If you do not have prior experience doing integrations – well – you have an education in front of you.

There are some things which are not taught in the classes, and not in the documentation.

In my case, I find the most successful method to use is (while working with a team comprised of a representative of the sending and receiving systems and me) to create a specification for each integration which is based on the sending and receiving system’s interface specification.

The specification being created is a ‘marrying’ specification (if you will allow me that term) which contains all of the detail required to accurately describe the provisions of the sending system and the needs of the receiving system and how the delivery of that integration will occur in Cloverleaf(R).

When the specification definition has reached a certain point I can begin to confidently build the objects (formats, tables, Xlates, Tcl procs, prorocols, etc.) knowing any changes in the specifications will mean minor adjustments in Cloverleaf(R).

For TCP/IP as soon as any system to which I do not currently have a connection says they are ready for connectivity (frequently before we have gotten very far in the specification process), I do a connectivity test using hcitcptest (a command line utility) which allows me to check connectivity without involving Cloverleaf(R), If I can get connectivity I can also check out a sample mesage from a sending system (if they have a message ready to go) and check out an acknowledgment (if one is expected) from a receiving system.

Thwere are similar tools available for SNA. For FTP just doing command line FTP can verify if the pieces are in place.

Once the specification is completed and you have built the objects, you have the whole process of unit testing, system testing, and other testing to verify stability, accuracy, functionality, etc. of the receiving and/or sending interfaces.

There is a lot more but that is a start.

In my mind integration (when done properly) is more encompassing than many (if not all) of the other disciplines within I/T. I think I am somewhat quaified to come to that opinion since I have actively worked in most of the I/T disciplines during my career. Consequently I find I use most of what I have learned in each of the other disciplines in the Integration discipline.

Jim Kosloskey

I’ve learned alot by browsing the topics listed on this board.  I try to log on every morning to see what the newest topics are.  It’s amazing some of the quality questions these users pose.  Good luck!

Lester,

Well it has been a while since I attended Level 1 and Level 2 however, I recall they went through the establisment of a simple integration which essentially traversed all of the major steps in Cloverleaf(R).

Did they not do that in the training you attended?

Jim Kosloskey

Hi Lester,

I think what you are looking for is a cookbook or standard way of doing interfaces between applications.  Unfortunately there is not just one way of doing things.  When we moved to Cloverleaf from Datagate several years ago, we had a consultant develop some of the first threads for some applications…..from there our team learned from what he had done and then using his threads as models and the level 1 education, we converted the rest of the Datagate to Cloverleaf.  It took us some time and we made several mistakes but we were able to learn ‘Cloverleaf’.

When I added a new person to the team, we had a more experienced integration engineer be his mentor as he learned Cloverleaf (after level 1 class).  The new person was able to glean information from the experienced person and have him as a resource as he developed his fist interfaces.

The suggestions by Jim are a good way for you to understand and document the interfaces as you are designing and building them.

Good luck from everyone on Clovertech….

Chris Brossette

DB/Integration Manager

MS Baptist Health Systems

cbrossette@mbhs.org

Amen.

“When you’ve seen one interface, you’ve seen…

One.”

The one thing I will suggest. I have done more interfaces then I can count. Having recently gone to a new job the one thing I have found is that people are using the source system to control what fields get sent.

I would suggest that the source system send everything and allow the engine to filter out anything you need to have not sent to receiving systems. If you don’t sooner or latter someone will want to add something to that list of fields from the source system that you know has to go back and test all the interfaces. If the engine already does it then you only have one translating to mess with.

John,

Good point.

I frequently see a similar desire with the Receiving system – that is just send me everything the sending system is sending.

In real life, however, it has been my experience the receiving systems do not want everything and in fact sending everything can cause issues.

I, for one, prefer to find out about those issues during an analysis (specification building) phase rather than after testing has begun – or – after it is rolled into production because neither analysis or effective testing has been accomplished. Of course we all know that at this point everyone will patiently wait for a correct resolution to be found rather than jerry-rigging something  😉

Besides refining the message to only what is needed by the receiving system makes for a smaller message and less network load.

A recent example, while somewhat extreme, that I had is a  receiving system’s analyst declaring the ADT mesages to the receiving system should just be an exact copy of the sending system. When just a cursory analysis was done it was discovered the receiving system only needed and wanted 12 fields. Our message size went from nearly 4000 bytes on the average to less than 1000 bytes.

Jim Kosloskey