There are many ways to use the EasyHL7 components to rapidly develop HL7 solution applications but it's best to keep a few things in mind that will make your experience easier.  One of the things that will help you immensely is to identify (if possible) exactly who you'll be exchanging HL7 data with.  We call these other parties Vendors, but they can also be referred as Trading Partners, Sending Application, Receiving Application.  Within the world of EasyHL7 you will see many references to Vendors and Vendor definitions, and Vendor HL7 Versions, and VendorPath and so on and so forth.  When we speak of Vendors and Vendor Definitions we mean what is the specific HL7 layout/version which your solution will use to exchange data with a particular Trading Partner, Sending Application, Receiving Application etc.

We recommend that as you identify a "Vendor" you may wish to exchange HL7 data with that you immediately create an EasyHL7 Vendor Definition for them, it's simple to do and only takes a couple of minutes (see Creating Vendors), and that you use that vendor definition in your solution.

Identify what you need to do both now and (as much as possible) in the future.

Gather the information you'll need (which is documentation and sample message files).

Documentation: It's human nature, when you're learning something for the first time to be embarrassed about asking questions for fear of appearing ignorant on a subject.  This keeps many developers new to HL7 from asking for the things that they will absolutely need to be successful.  Every application that is HL7 aware should have an HL7 Implementation Guide (yes, you'll be expected to have one too).  For a "Sending Application" this document specifies what kind of HL7 messages an application produces (HL7 Message Types and Events) and what data (HL7 Segments) is contained in those messages.  For a "Receiving Application" it should detail which kinds of HL7 messages they will process (HL7 Message Types and Events) and what data (HL7 Segments) must be contained in those messages and which fields within that data are absolutely required. If an application intends to both send and receive HL7 messages then their document should have 2 sections.  Vendors should OFFER this document to you, and if they don't, they would likely be very surprised if you don't ask for it.

If you answered Yes to item 2 (you need to interface with more than one application), and No to item 3 (you have to be flexible), then it is VERY likely that you will need to produce a separate HL7 Implementation Guide for EACH Vendor.  Don't worry, this is not uncommon, but it is important.

You should ALWAYS be able to ask for and receive the HL7 implementation guide from a potential trading partner.  It is never wrong to ask for it.

Sample Files: When you are the "Receiving Application", and you are trying to develop the interface between your application and Vendor <XX>, you should always be able to ask for, and receive, sample HL7 message files.  While anyone should be able to do this, some vendors may not like to. 

Remember: When you develop your HL7 solution(s) you will also be subject to the same expectations from your trading partners.  They will expect you to have an HL7 implementation guide AND (if you send HL7 data) they will expect you to be able to produce sample messages for them on demand to help THEM develop interfaces to you.

If it's your first time: If you've never developed an HL7 interface before, obviously you won't have an HL7 implementation guide of your own.  So how do you make one?  The easiest way is to copy someone else's.  If your application needs to receive HL7 messages, contact the trading partner that's most important to you and obtain their implementation guide for how they SEND HL7, then create your initial document as a "mirror" image of theirs as much as is possible.