EHR intercommunication / client

Question

So, I'm researching methods for building a client interface for existing EMRs. I've read tons of info on HL7, as well as the various coding schemes, but I'm still really clueless.

For anyone whose worked with an EMR before: is it possible to build a web interface that can use HTTP-POST and HTTP-GET requests to pull/push data to the server database? Or would you have a separate database for the client, say a web application, then use some interface engine like Mirth to communicate between the EMR database and the web application?

Answer 1

A web service API is definitely a way to go. One benefit to this is that you can get https almost out-of-the box for encryption of data in transit.

The way we have configured our EMR is that we have a tcp server accepting incoming hl7 messages from certain IPs which connects directly to our EMR database. This can be beneficial by separating emr and interface processes (You don't have to restart your whole EMR if the interface goes down, for instance).

Another good feature would be to have a token system for pseudo-authentication. This only works if you are going over a secure connection though.

If you aren't into writing your own tcp server (not that hard), an api-based server is probably just as good.

EDIT: What language(s) do you think you'll be using?

Other things that you might run into:

1. Some applications prefer file drops to direct calls (either url or tcp)
2. Some vendors will have their own software that sits on a server of yours
3. Don't forget the ACK.

Answer 2

I don't see why you couldn't do this. You would need to build the web service to handle requests with a specific Uri. When this Uri is called the web service uses the data sent with the request to make changes in the database.

Once you had the web service built, you could build some sort of front-end that displays your information to the user. And makes HTTP-GET and HTTP-POST calls.

There is a lot of flexibililty in what you are trying to do... so go with a plan for sure.

In general though you should be able to accomplish what you need to do by building your own web service and front-end application that is able to manipulate an EMR database.

Answer 3

It really depends on your architecture and requirements.

Architecture 1 If you want your client to be web based, but your client is a separated app from your backend, then the web sends the info using HTTP to your client app server side, and then, that will send info to your EHR backend (another app). That second communication might be written using a standard, that will help you on integrating more systems with your backend in the future. So that interface can be HL7 based, if HL7 v2.x is used, take a look at the MLLP protocol: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=55

This is the most performant way of communicating HL7 data. If you don't want to deal with TCP, there is a proposal for HL7 v2.x over HTTP. HAPI implemented that: http://hl7api.sourceforge.net/hapi-hl7overhttp/

If you don't want to use HL7 v2.x but HL7 v3 (a different standard, not really a version of 2.x) or CDA, you can use HTTP or SOAP.

Architecture 2 But, if you want your client just to be a UI on the user side (browser), HTTP POST will suffice to send info from the browser to the server. That means your EHR is a centralized EHR with a web iu.

In the 1st architectural case, first case you'll probably have multiple client apps (full EMRs apps) and a backend EHR server (centralized backend). On my developments I follow this second architecture.

Also there Mirth might help to manage all the communications between client apps and backend apps. In the 2nd case, using Mirth is nonsense, is just a web application and the client communicates directly with the web server. Of course, you can use Mirth as a web server, but that's not it's role, it is an ESB no a web server.

Hope that helps!