Version 4.X (released November September 2007)

Version 4.x of the EasyHL7 ActiveX toolbox represents a major update for this set of tools.  New properties, methods, and some extremely powerful new objects make the EasyHL7 components the

The CommandoProcessor object was added.  You can now design HL7 solutions entirely in the Commando HL7 Workbench, export them and run them independently using the EasyHL7 Component Toolbox.

The MessageReadObject Event was added to both the HL7File object and the EHL7Processor object.

Many methods added to the EHL7Message object to aid in message manipulation.

Methods added the HL7Vendors object to support Base64 Encoding.

Online product activation was added.

Version 3.3 (released November January 2007)

Version 3.3 of the EasyHL7 ActiveX toolbox is a bug-fix release.  There has been one update to fix a minor bug in the EHL7Interface DLL and three new read only properties were added to the HL7Vendors object and the eUtilities object.

A problem in the PrintPreviewMessage() method of the eUTILITIES object was fixed.

API Version properties were added to the eUTILITIES object and the HL7Vendors object.

Version 3.1 (released November 2006)

Version 3.1 of the EasyHL7 ActiveX toolbox is a bug-fix release.  There have been two updates to fix a minor bug in a property implementation from version 3.0 and a general bug which was hindering registration in Non-English versions of MS Windows (see System Installation for further info).

A problem in the implementation of the TruncateEmptyFields property in the EHL7Message object was fixed.

A problem was fixed which hindered registration for clients running a non-english language version of MS Windows.

Version 3.0 (released August 2006)

Version 3 of the EasyHL7 ActiveX toolbox was a maintenance release to maintain version compatibility across our suite of HL7 related products.  There has been one update to fix a minor bug in the HL7File object.

The HL7File object has had a bug fixed that caused it to fail if the Segment Delimiter of the vendor object was set to a Line_Feed (Ascii Character 10, Hex 0A).   This was a very minor problem since you are NEVER supposed to use the Line Feed character in HL7 messages.

The TruncateEmptyFields property was added to the EHL7Message object, the HL7File object and the EHL7Processor object.  When set, this property will remove trailing empty fields from HL7 segments.  See the definitions in EHL7Message, EHL7Processor and HL7File objects.   **NOTE: This property was not implemented correctly and is fixed in version 3.1

The main installation program was changed, and EasyHL7 now delivers in a Microsoft Installer (.msi) file.  See System Installation for instructions.

Version 2.2 (released January 2006)

In version 2.2 of the EasyHL7 components we have continued to evolve our product adding new functionality.  As we make these improvements we have maintained FULL backward compatibility all the way back to version 1.5 so any solutions (or type libraries for our C++ and Delphi users) you have developed with the prior version should not need to be recompiled.  If you are using type libraries and problems do occur, try recreating your .tlb files. 

The EHL7Processor object now has the InputFileError() event which will allow you to directly respond to files which contain invalid HL7 data.  In prior versions the EHL7Processor object would only move files to the ERRORPATH folder if a physical or network error occurred or a code fault existed.  Ironically, practically ANY error of this type would render it impossible to actually move the file to the ERRORPATH folder which negated any real effectiveness of that piece of functionality.  No code changes are required for solutions already developed with prior versions  to respond to this event unless you want to do something specifically (like log errors, alert the user or override the default error handling so that the file is not moved to the ERRORPATH folder)

The HL7File object now has the HL7FileError() event.  The HL7File object is a lower level object used by the EHL7Processor object and by EasyHL7 customers who prefer to develop their own version of the EHL7Processor object.

At HermeTech we always welcome input from our customers so don't hesitate to contact us at HermeTech Support with ideas or suggestions.

Version 2.0 / 2.1 (released October 2005)

In version 2.0 of the EasyHL7 components we have continued to evolve our product adding new functionality.  As we make these improvements we have maintained FULL backward compatibility to version 1.5 so any solutions (or type libraries for our C++ customers) you have developed with the prior version do not need to be recompiled.  Version 2.1 was a maintenance release to correct a corrupt OBR segment definition in the Default Version 2.3 vendor definition.

In the EasyHL7.exe application you can now copy HL7 segment definitions from one vendor to another (see HL7 Definition Editing for further information).

The EHL7Message object now supports dynamic loading of segments and fields that have not been defined in the Vendor's HL7 definition when opening an HL7 message string.  See CreateFromHL7().  In prior versions, if you attempted to open an HL7 message that contained segments not defined in the vendor's HL7 definition, it would fail (gracefully).  Now unrecognized segments will be loaded into the message object with a description of "Undefined Segment".  All fields and components are defined as "ST" datatype and are accessible via the standard .GetFieldValue(), .GetEscFieldValue() methods.  In addition, if (in a segment that is defined) additional fields (or components of fields) are detected which exceed the vendor's definition they will also be dynamically loaded.  In prior versions field and component parsing stopped at the vendor definition's limit when loading an HL7 message  into a message object.  Note that this applies only to messages in HL7 format, not the proprietary EasyHL7 XML message format.

The registration process was made clearer.

Version 1.5 (released August 2005)

You can now print HL7 messages in several different ways both from the file manager and from code.

The EHL7Message object now supports dynamically reading Encoding characters and Field Separators from within the HL7 message data.  See CreateFromHL7()

New 'Escaping' methods lets the object make sure your data is 'safe' when setting field values.  See SetEscFieldValue(), GetEscFieldValue(),  VendorEscData()and VendorUnEscData()

The EHL7Message object now has a  SegmentFieldCountmethod to count fields in a segment object.

Memory management improved to handle very large HL7 messages (over 100 segments).

The HL7Vendors object now has individual properties to reference the individual EncodingChars.  See ComponentDelimiter, EscapeDelimiter, RepeatDelimiter, SubComponentDelimiter.