EMR Hardware part 2 – network connections

As I discovered in my quest to set up a functioning EMR, an electronic record does not function with a computer alone. In order to work, a client computer is needed to access the server, it needs to connect to a network, and there are considerations to be made for security and reliability. As the topic is broad, today I’ll focus on what I learned about network connections, and discuss client computers, security, and reliability later. Perhaps a little bit of background will make the details relevant to networking clearer.

For the total beginners, EMR software usually runs on a server computer; the user interacts with the software using a client computer that connects to the server, rather than operating the server computer directly. This is similar to how your computer is accessing a server to view this webpage. The nice thing about OSCAR is that it runs through a web browser; therefore, provided the client computer can connect to the server, any computer with a web browser can be used to access and operate OSCAR.

There are different ways the client computer can connect to OSCAR. One option is over a local network – the computers in the office connect to each other, but not the wider Internet. Therefore the server is located on-site and remote access is not possible. Another option is to connect through the Internet, which requires that the server be connected to the world wide network, but it could then be accessed anywhere with an Internet connection. One could connect to OSCAR locally while in the office and over the Internet while at another location. Alternatively, OSCAR can be run on someone else’s server (Application Service Provider, or ASP). This last option is not really DIY – the server is in someone else’s hands, in a physical sense and in terms of the upkeep. Since I needed remote access but I wanted some control over the setup, I opted to set up my OSCAR server at a central location so that I could access it at the various clinics where I work.

If one only plans to access the server locally (a very secure, but less convenient option), then a simple network switch connecting the computers should suffice. For remote access, Internet connections get involved and you will need a router.

When considering the Internet connection, the upload speed is very important. The server will be serving up files to the client computer and therefore, especially if multiple people will be working on the EMR at once, the server needs a fast upload connection. The problem with the average high-speed Internet connections is that it is biased towards fast download speed so that users can watch movies, download music, etc. Uploading is much less of a priority, and understandably so – if everyone were running a file sharing service or a web server at home it could suck up bandwidth pretty quickly. If the upload speed is too slow, it bottlenecks the server. I’ve been told that an upload speed of at least 3-5 Mbps is required and in my experience, is sufficient.

The router is basically a small computer that directs internet traffic. You will need a router if you have more than one computer connected to the Internet. There is a huge range of routers on the market – ranging in price from $20-30 to several hundred dollars.

Since my home Internet provider uses a dynamic IP, the router needed to support Dynamic DNS (Domain Name System). The computer’s IP address is like its postal address on the Internet; when one enters a URL into the browser, a DNS service uses the URL to look up the correct IP address and directs the client computer there. If the server has a static IP address, then it’s “location” on the Internet is always the same. If, however, it is a dynamic IP, it might change from time to time – a DNS service’s information might go out of date and then the server would be impossible to find remotely. The solution is Dynamic DNS – the router gets the server’s current IP address at certain intervals and feeds that information to the DDNS service, so even when the IP changes, the same URL will get you there.

There are many DDNS services available, for example, subscription services from Dyn. If you are really on a budget Afraid.org offers a free DDNS service; you may need to modify your router firmware to use this service (see below) as the commercial routers that I’ve owned tend only to support a few of the larger subscription DDNS services.

There are commercial-grade routers that have more advanced wi-fi encryption, virtual private network support, and faster connections, but in my experience it isn’t necessary to pay for most of these features. Given the slow upload speeds of most connections, a Gigabit router isn’t necessary – a standard 10/100 Ethernet router, even if it tops out at 100 MBps, will not be the limiting factor. Almost any old $20 second-hand router will do; most of the “advanced” features on the more expensive routers have to do with the software installed on them, rather than the hardware, and the software can be altered. This means that if your cheap router doesn’t support DDNS, the firmware can often be replaced with DD-WRT, an open-source router firmware, that does support DDNS. When my D-link router died after about 5-6 years of service I replaced it with a second-hand Linksys WRT54G (first released around 2002) and flashed the firmware so I could use DDNS. The instructions for doing this are widely available on the Internet; it takes a few hours and some anxiety is involved due to the potential of “bricking” (rendering inoperable) the router if the procedure isn’t followed properly.

Now that we’ve discussed the connecting hardware, we can look at the computer that will do the connecting – the client computer.