HL7 via SFTP
By: Johnathon Wright on: February 20, 2013
This page documents the process of creating an HL7 interface between my client's "micro-EMR" and a medical laboratory named "BioReference":bioreference.com
BioReference presented me with two interface options: * install software on my windows machine. Their software would dump files into a directory of my choosing. * SFTP
Since our application runs on Linux, I had to choose SFTP. Per my contact, Raxit, they did not have any other available interfaces.
h2. On whether or not SFTP is a good idea
I recently compared passing messages via FTP to sending emails by opening up a share and typing those messages in notepad. It's a good analogy -- I can say it was me that sent it, and it probably was, but in the end, even though email is obviously just as insecure if not less secure, the lack of a "sender" really bothers me.
h3. Pros * widely used * easy-ish to implement (though I have to check for new files and that's kinda sloppy... ) * Of the one option presented to me, this was one of them. * Unlike SMTP, messages will not sit on a business partner's machine, waiting for me to retrieve them. * SFTP sits on top of SSH which is unquestionably very secure in terms of preventing outside parties from reading the data while in transmission, barring a man-in-the-middle attack.
h3. Cons * there is no queue to be checked; no intrinsic marking things as read. * If the server goes, this goes too, and no way to know what was lost. * though in the end, this app isn't (to use NASA terminology) "man-rated" (no human lives depend on it.) * not clear to me that it conforms strictly to HIPPA standards. However, all the major companies use it, and they have more lawyers than my client, so it seems safe to assume it has been vetted. * no way to send an ACK * I am supposed to log who sent the file. Unlike SMTP or whatever, there is no listed sender. (Though of course, SMTP senders can be faked... )
h2. Security Concerns
Do I really want to give these people a user account on my server? NO.
Under normal FTP conditions (or SFTP), a user who FTPs into your machine will have read-only access to many, many files, such as those in /var and /etc. Since locking down Linux is not my full time job, this seems like a pretty terrible idea to me. Fortunately, the people at RackSpace (long may they live) had some suggestions to help me make this more secure.
change port Change your SFTP port to something obscure to decrease attempts to access your machine.
shroot is a tool that allows you to change the apparent root for a user so that users see only the files in a specific directory, and nothing outside it.
h2. Other Utilities
tripwire is a program that I may be able to use to simulate a better interface... it should be able to watch this directory and notify my app, perhaps by posting to a URL or something, that a new file is ready for processing.
h2. Implementation
h2. References
http://instagrati.com/tag/subsystem-request-failed-on-channel-0/ http://www.faqs.org/docs/securing/chap15sec122.html http://www.pureftpd.org/project/pure-ftpd