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?
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:
Some applications prefer file drops to direct calls (either url or tcp)
Some vendors will have their own software that sits on a server of yours
Don't forget the ACK.
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.
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!
Related
From a Web Server running in Windows 2012, I would need to send messages to specific clients. These clients are Delphi applications, over 2000. Each message is for a specific client, no broadcast.
Which technology can I use? I am totally new on this issue.
I am seeing Websockets, SignalR (that is based in Websockets), MSMQ, RabbitMQ, ...
MSMQ: Seems a good solution. Cons: It only works in Windows. Maybe in a future, I need to add other platforms as clients.
RabbitMQ: It is also good,but I think that it provides too features for my scenario. Basically I only need to send messages from server to specific clients.
SignalR: I am confused. It seems basically for web browsers, not for client applications. It seems a simple solution.
Basically, I am looking a simple and basic solution that I can implement in Delphi to receive messages from a web server.
WebSocket (a HTTP upgrade) is a light-weight option and also available for Delphi clients:
WebSocket is designed to be implemented in web browsers and web
servers, but it can be used by any client or server application. The
WebSocket Protocol is an independent TCP-based protocol.
See WebSocket client implementations for Delphi
RabbitMQ and other solutions are useful for example if the client could be offline while the server wants to send the message. The message broker provides a store where the message will be waiting for the client, even if the server restarts. Also a message broker will reduce load on the HTTP server.
I have had experienced with iOS development but no Client Server type applications.
I have heard about HTTPS, REST, JSON, etc. I am confused on the differences.
My app that I want to build is getting a list of data to output to the user and also sending a form to the server to be processed. E.g. A Membership Application to the Server with personal information and other pertaining information to be stored in the server. I also need the connection to be secure and the user must logon to the server with a username and password.
How does my app communicate with the server? Is it using NSURLRequest?
What is the best method or protocol to accomplish this?
Thanks!
HTTPS, REST, and JSON are different tools you can use when performing networked operations (more specifically, a secure protocol, a web service architecture, and a method of object serialization, respectively). If you don't know what these mean, I would do a little reading before attempting to build an iOS app that functions as a client. The link johnathon posted in the comments is a little low-level for what you're wanting to do, but searching around for "consuming a web service with iOS" might be good.
Also, does the service already exist? If so, your task is essentially to understand how to communicate with the server.
Once you're a little more up-to-speed on the fundamentals, however, the AFNetworking library is phenomenal.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
In a DELPHI 2007 application that I am developing some prospect clients just found interesting to be able to share data and information with each other.
They all have the same application.
All have independent Databases
But all have the same installed application and there are some data types that they might want to share (replicate) between their databases.
How can I enable them to share data with other users of the same application program, but not to everybody on the whole internet.
I would like this to be as automatic as possible, as I already have considered approaches that involve manually sending emails.
I know Datasnap is an option, is there any other.
UPDATE:
The idea is to enable companies that have the same application to be able to share data.
They should be able to select what partner and what to send.
I have been investigating datasnap, but would like to know if there is another way to do this
Another standard way to connect distributed applications and share data and information is through some Message-oriented middleware (MOM). There are many open source middleware products (message brokers) available, which can be used over Delphi client libraries, even in multithreaded Delphi server applications. (Disclaimer: I am the author of message broker client libraries for Delphi and Free Pascal)
There are many essential differences between web services and message brokers, like peer-to-peer and publish/subscribe communication models. They also play a key role in enterprise application integration patterns.
One standard way to connect applications to other applications is to make a web-service, and make a client that consumes that web-service, called a web-client. Technologies like SOAP and REST refer to such web service and web clients.
Your question is vague, perhaps due to english not being your language, but you should probably edit it and be more specific.
If all your applications are going to talk directly to each other that is called "peer to peer networking" and there are huge problems with enabling that kind of communication directly over the internet. It is much easier if you build a server that all these applications will connect to.
As a sample, consider the IRC Chat service, and consider writing a Web Service that will be the Chat Server, and consider all your clients to be "Chat clients". Sharing data could be the same idea as creating "rooms" or "channels" on a chat server.
I get the idea that you want something like a Peer to Peer Data Replication Service. I think that the closest you're going to get to that is something like "RSS Feeds" (used by blog syndication services). You subscribe to them via a simple web service, and pull down the new content on some periodic basis. Since that data has to be published to a central server, that means, that a peer to peer approach is out of the question. If you don't have your own web server running on a web hosting service, or on a "cloud", and you need a truly peer to peer solution, I am not aware of any way to do that, at least not without an incredible custom engineering effort.
I have some delphi code which, given a list of items, calculates the total price taking into account any special deals that might apply.
This code is non-trivial to rewrite in another language.
How should I set it up to communicate with a website running on the same server? The website will need to ask it for a price every time the user updates their shopping cart. It's possible that there will be multiple concurrent requests.
The delphi code needs to maintain an in-memory list of special deals, periodically refreshed from a database. So it cannot simply be executed every time or anything as simple as that.
I don't know what the website is written in, or even which http server it runs under, so I'm just looking for ideas or standard methods.
It sounds like the win32 app is already running as a Windows Service on the box. So, if you can't modify that service, you are going to have to deal with whatever way it wants to accept and respond to requests. This could be through sockets or some higher level communication protocol like web services.
You could do a couple of things. Write an assembly that knows how to communicate with the service and have your web site use that assembly. Or you could build a shim service that knows how to communicate with the legacy service, but exposes communication over higher level protocols such as web services. Either way will have the benefit of hiding the concurrency, threading and communications issue behind an easy to call interface, but the latter will make communicating with the service easier for everyone going forward.
If you can modify the delphi app to take an XML request and respond with an XML answer over a TCP socket (ideally using the HTTP protocol), you will be able to make it interoperate with most web server frameworks relatively easily. But the exact details of how to make that integration happen will depend on the language/framework it was written in.
If the web server is on windows you can compile your delphi app as a DLL that can return XML or HTML, taking parameters as part of the URL or a POST operation. Some details on making a Delphi DLL for web servers are here.
It doesn't matter what web server or OS the existing system is running under. What matters is what you want YOUR code to run under. If it is windows then the easiest solution would be to use WebBroker and write a custom ISAPI application, or use SOAP to expose web services. The first method could be used if you wanted to write a rest like API for instance, the second if your web application has the ability to consume web services.
Another option, if you are running both on the same box under IIS, is to create a COM/Automation object which you then invoke via server side scripting (ASP). If the application is an ASP.NET application, then I would use PRISM to port your code into an assembly.
I have done this with a quite complicated workers compensation calculator. I created a windows service using RemObjects Sdk. The calculations are exposed as a soap method so it can be accessed by nearly anything.
It's not necessary to use RemObjects in the service but it makes it much easier to do as it handles a lot of the underlying plumbing. The clients don't need RemObjects, they just need to be able to call soap methods. Nearly any programming langugae can do that.
You could also create an isapi dll for IIS that exposes a soap interface. This would be useful if other websites on different servers needed access to the methods. However I have handled this in my case by opening a port in the firewall to access my windows service.
There is a lot of examples on the web. A couple of places to start reading are About.Com and Dr Bob.
Torn this app into Windows Service. Write Web Service that will communicate with your windows service. You should spend some time designing your Web Service, because this Web Service is going to be your consistent interface, shielding old Delphi app. So in the future whenever you will want to write web app, mobile app, or whatever you will imagine, you will have one consistent interface – XML Web Service.
A popular way to integrate a web application with background services is a message broker.
The message flow would be:
the web application sends a "calculation request" message to a message destination on the message broker, which contains all needed parameters and also a correlation id to match the calculation request with the response from the Delphi service
one (or, in a high availability / load balanced environment more) Delphi services handle the messages: pull the next incoming message, process it by feeding the parameters to the calculation engine, and send a "calculation result message" back to the web server
the web server can either synchronously wait for the response (and discard responses which have no matching correlation ide) and build the result HTML document, or continue with other tasks and asynchronously receive the calculation result in a separate thread, for example in a Ajax based web application
See for an introduction this slideshow about the Dopplr image service:
http://de.slideshare.net/carsonified/dopplr-its-made-of-messages-matt-biddulph-presentation
If you can make it a service (but not a library), you have to do inter-process communication somehow - there are a few ways to do this on Windows:
Sockets directly which is hardest since you have to do marshalling/auth yourself
Shared Memory (yuck!)
RPC which works great but isn't trivial
DCOM which is easier but a pain to configure
WCF - but can you call it from your Windows Service written in Delphi?