EHL7Processor Object

The EHL7Processor is used primarily to create and execute processing profiles. Processing profiles can be either created at run-time or saved and loaded from ini files on disk. It uses all of the other objects as needed. This object raises events so it is suggested that you use early binding and withevents to get the full benefit.

A non-modal processor. When the ProcessProfile()method is called, control returns immediately to your application and you can operate entirely on the events produced by the object. This means that the object can be called from your own DLLs or ASP type applications or System Services with little fear of timeout events and allow your application to perform other tasks.

2.	A jumpstart on programming. When developing your own solution like this, you actually begin the project already on third base. Allowing you much more time to devote to managing the data which is the whole point of the solution.

4.	A standard consistent development platform. All of your solutions can be easily developed using the same 'templates' of code, leaving only smaller vendor-specific changes needed for each solution and greatly increasing the opportunities for code re-use.

5.	An intelligent file system monitor. When executing, the InboundPath is polled at specified intervals for files with the extension set in the InboundExtension property. Events are fired frequently:

At it's core the EHL7Processor object basically monitors a file system folder for the presence of HL7 data files. When files are detected in the folder the object will then:

1.	Build an internal linked list of the files in the folder (ignoring 0 byte files or files that are locked when the list is being built) which will contain different file attributes (name, date, size etc).

3.	Process that list in the sorted order by opening each file, parsing out all of the individual HL7 messages contained in that file, and then raising events into your code for each message.

There can be a problem with item number 2 above if you don't understand the limitations of the MS Windows operating system and the FAT32 file system. At the time of this writing on all of the 32-bit MS Windows operating systems using a FAT32 file system folder DO NOT return the milliseconds portion of any file's timestamp. An NTFS file system DOES NOT have this problem and does return a file's complete timestamp including the milliseconds portion.

What does this mean to me? The impact to you the programmer can be small or large depending on the type of interface you are trying to design. Consider the following scenario.

Scenario 1. You have a folder with 4 HL7 data files with 1 message each named A.hl7, B.hl7, C.hl7 and D.hl7. They are all ADT messages (Patient Demographics) and they are all for the same patient. In addition because of some short-sighted programming the application that produced these data files has produced them all within the SAME SECOND so they were all created on the same day at 03:15:10 PM local system time. On top of that the files were produced by 3 different modules of the source program which names the files based on the module that they came out of so that in reality B.hl7 was produced first, then D.hl7, then A.hl7 and finally C.hl7. So how does the processor know in which order to process these files. If the files reside on a FAT32 file system their datetime stamp is IDENTICAL and the processor would end up processing them in the secondary sort (file name A, B, C, D). On an NTFS file system, the processor would be able to detect the difference between the files based on which MILLISECOND the files were updated, thus allowing the files to be processed in the correct order. NOTE: even in MS Windows Explorer if you try and sort these files by DateTime the resulting list is in error.

What can I do? If you see a potential impact to your application you can do several things to make sure that things go smoothly.

Try to make sure that whatever application is producing the HL7 data files uses a file naming convention which insures that when files are sorted alphabetically by file name they also come out in the proper date time order. In other words, do not name your HL7 data files <ControlID>.hl7 or <PatientID>.hl7. Use a dynamic file naming convention whenever possible like <DateTimeStamp yyyymmddhhnnss>.<rollingsequencenumber nnnn>.hl7 where the rollingsequencenumber either resets back to 0001 every second or rolls back to 0001 when it exceeds 9999.